21 век на дворе. Почему исходные данные нельзя переварить в нормальный де-факто стандартный EPSG:4326 и визуализировать в любой из proj4-проекций? Исходный формат и рабочий формат — вещи немного разные.
Или вам по техзаданию ещё и рамки с разметкой от SXF-недокарт оставлять надобно? :3
Натыкался на это, когда репортил перформанс-проблемы GPU Canvas в Chrome.
«Мы не можем повторить ваш репорт, потому что у нас нигде нет такого старого GPU, поэтому мы его просто заблеклистим».
ATI Radeon HD 4225.
Это шестая или седьмая реализация чтения GDAL'овских стандартных форматов, проходящая мимо меня. В двух случаях, когда проект пошёл развиваться дальше, собственная имплементация была выкинута и заменена на что-то другое.
Чем не подошёл тот же lwgeom из postgis? Там и чтение WKB реализовано полностью, и в geos интерфейсы есть, и в geojson сериализация вполне себе ничего. Вот, 250к linestring'ов в виде 59-мегабайтной таблички только что за восемь секунд в geojson сконвертилось, выгребясь из базы на моём не самом новом ноуте.
Соответственно, хочется понять, что движет людьми, раз за разом переписывающими стандартные библиотеки вместо дописывания нужных вещей, которых в них нет. Хотя бы в виде «раньше работало часы на таком-то датасете, теперь минуты».
а сколько оверхеда получается в численном выражении?
«снижает производительность», это, конечно, плохо, но в очень большом классе сценариев вполне приемлимо.
Ребята из хрома лучше всего убеждаются рабочей демонстрацией, в которой «вот это вот не тормозило бы/не глючило бы, если бы у меня была такая-то возможность: ...»
Адрес как раз валидный. Да и код тоже, просто начиная его дизассемблировать с разных точек можно получить разные ассемблерные листинги. Вот такая вот расплата за CISC.
То ли дело PIC какой, где длина команды фиксирована, и программа вообще лежит отдельно от данных :)
Не путайте просто «снимки из космоса» и «снимки из космоса, пользоваться которыми не разрешил правообладатель». В 21 веке почти все карты рисуются по снимкам из космоса, вопрос в том, есть ли явное разрешение от владельца этих снимков. Bing, Yahoo, Космоснимки дали OpenStreetMap такое разрешение, Google и Яндекс — нет.
На самом деле никакой проблемы нет даже без релейшенов. На openstreetmap.by/ название в «хлебных крошках» берется как «name:be с ближайшей улицы, у которой оно есть, и при этом name у этой улицы такое же, как addr:street на доме». Достаточно однозначное соответствие и без сложных для новичков релейшенов — оно «просто работает».
Или вам по техзаданию ещё и рамки с разметкой от SXF-недокарт оставлять надобно? :3
«Мы не можем повторить ваш репорт, потому что у нас нигде нет такого старого GPU, поэтому мы его просто заблеклистим».
ATI Radeon HD 4225.
Это шестая или седьмая реализация чтения GDAL'овских стандартных форматов, проходящая мимо меня. В двух случаях, когда проект пошёл развиваться дальше, собственная имплементация была выкинута и заменена на что-то другое.
Чем не подошёл тот же lwgeom из postgis? Там и чтение WKB реализовано полностью, и в geos интерфейсы есть, и в geojson сериализация вполне себе ничего. Вот, 250к linestring'ов в виде 59-мегабайтной таблички только что за восемь секунд в geojson сконвертилось, выгребясь из базы на моём не самом новом ноуте.
Соответственно, хочется понять, что движет людьми, раз за разом переписывающими стандартные библиотеки вместо дописывания нужных вещей, которых в них нет. Хотя бы в виде «раньше работало часы на таком-то датасете, теперь минуты».
«снижает производительность», это, конечно, плохо, но в очень большом классе сценариев вполне приемлимо.
Два умерли в первые две недели, ещё один продержался год. Меняли по гарантии, так что бекапы, бекапы и ещё раз бекапы.
Всего дисков порядка пяти, те, что отданы под ось и прочие почти статические нужды — до сих пор нормально работают.
Продолжаем, потому что аналогов по скорости произвольного доступа нет.
То ли дело PIC какой, где длина команды фиксирована, и программа вообще лежит отдельно от данных :)