О документации
Так как впереди маячит ответственный дедлайн, то в выходные я был на работе: генерировал GeoTIFF из геологической карты, выгруженной из софта Шлюмберже. Сама логика простая - переводим карту в двумерный массив, property-value отображаем в Hue, S и L фиксируем и пишем все в ARGB. Квест начался, когда выяснилось, что GeoTIFF штука не самая распространная, и без GDAL его писать непросто. Потыкался в сишные сырцы, с горем пополам сделал. Отдельных слов удостаивается фиксированный PixelScale для географических координат.
А потом я начал это грузить в GeoServer. Дело даже не в том, что Geoserver 2.6 нормально не работает с REST API. И даже не в том, что документация к REST API очень куцая. Меня раздражает сам подход - если нет автогенерированных доков для API, а в исходниках сплошь и рядом Json.SetValue(str, object), то лучше уж используйте wsdl. Там хоть понятно что это говно может.
В остатке: REST без внятных документов по API - кусок говна. Хоть бы OData использовали, что ли. Можно сгенерировать клиент, а не велосипедить свой с dymanic (спасибо MS за него - с разными контрактами для одной и той же сущности на POST / PUT и GET без динамической типизации было бы очень больно).
А потом я начал это грузить в GeoServer. Дело даже не в том, что Geoserver 2.6 нормально не работает с REST API. И даже не в том, что документация к REST API очень куцая. Меня раздражает сам подход - если нет автогенерированных доков для API, а в исходниках сплошь и рядом Json.SetValue(str, object), то лучше уж используйте wsdl. Там хоть понятно что это говно может.
В остатке: REST без внятных документов по API - кусок говна. Хоть бы OData использовали, что ли. Можно сгенерировать клиент, а не велосипедить свой с dymanic (спасибо MS за него - с разными контрактами для одной и той же сущности на POST / PUT и GET без динамической типизации было бы очень больно).