Исчезающие точечные объекты в Geoserver с использованием WMS


10

У меня есть шейп-файл с примерно 6 500 точками по всему миру, который я пытаюсь использовать в Geoserver 2.2.1 с использованием WMS. Все было в порядке с этим, пока я не реализовал функцию фильтрации в моем клиентском приложении, которое использует листовки. Когда я добавляю CQL_FILTER (атрибутный фильтр, а не пространственный) в запрос WMS, при уменьшении масштаба я заметил, что отсутствуют функции. Когда я увеличивал масштаб, они иногда появлялись снова, но не всегда. Смотрите изображение ниже -

Бок о бок сравнение

На уровне масштабирования слева Атланта не отображается. Когда я увеличиваю, это так. Однако иногда даже точка в Тампе не отображается на уровне масштабирования слева. Если я уменьшу еще 3 уровня, точки вообще не будут отображаться. Я не уверен, что проблема заключается в параметре CQL_FILTER, так как с 6500 точками трудно заметить несколько пропущенных точек в глобальном масштабе, но конкретный фильтр, который я показываю здесь в качестве примера, фильтрует только до 3 функций, и когда От 1 до 3 из них отсутствуют в зависимости от уровня масштабирования, это особенно заметно.

Я могу воссоздать такое же поведение в предварительном просмотре слоя собственного геосервера с помощью фильтра CQL в дополнительных параметрах карты, поэтому я вполне уверен, что это не мое клиентское приложение.

Что касается моих собственных шагов по отладке этой проблемы, я попробовал файл стиля / sld по умолчанию, чтобы исключить мой собственный стиль слоя. Я отключил все кэширование, которое мне известно. Я дважды проверил правильность моих проекций - я создал шейп-файл в ArcGIS 10, используя WGS_1984_Web_Mercator_Auxili_Sphere в качестве проекции, и для слоя задано значение EPSG: 3857 в геосервере, что, я думаю, эквивалентно. Я также обновил геосервер 2.2 до 2.2.1, и у меня была та же проблема в обоих. Я также удалил файл пространственного индекса геосервера (.qix) и позволил ему воссоздать его, поскольку я видел похожие проблемы в Arc с поврежденными пространственными индексами, но, очевидно, это тоже не сработало.

Вот снимок из собственного предварительного просмотра слоя Geoserver с включенным фильтром CQL и увеличенным в той же области, как показано выше. Красный круг примерно там, где я должен видеть другую точку (Атланта).

Пример Openlayers

Я пытался настроить все остальные настройки, о которых я могу думать, но мне не повезло. Я также просматривал журналы геосерверов и включал подробные журналы, и не вижу никаких ошибок / исключений. Я также не вижу плохих запросов в инструментах разработчика Chrome.

Если мне не хватает какой-либо важной информации, я предоставлю все, что смогу, но это внутреннее / непубличное приложение.


1
Исключая очевидное: есть ли у вас случайно зависящие от масштаба стили? (т.е. точка отображается только между определенными шкалами)
unicoletti

1
Можете ли вы проверить, что значения в VENUE_TYPE являются действительными / согласованными? Непоследовательные результаты, которые вы видите, могут быть вызваны тем, что функции возвращаются в другом порядке (из-за небольших различий в bbox), и один из них в некотором роде является «плохим», вызывая остановку рендеринга до того, как он попадет в Атланту. Возможно, было бы целесообразно протестировать экспорт данных в другой формат, чем 1) проверка всего, что было перемещено, как ожидалось, и 2) повторное тестирование фильтра / рендера
tomfumb

1
@unicoletti На слое, отображаемом на скриншоте, есть зависимости масштаба, но я вижу тот же результат, когда использую стиль точки по умолчанию, предоставляемый Geoserver, который не имеет зависимостей масштаба. Я вижу, что точно такие же точки исчезают в тех же масштабах. ,
MWrenn

1
@tomfumb Я просмотрел значения в столбце VENUE_TYPE, и все они буквенно-цифровые, кроме случайной косой черты '/' или амперсанда '&'. Я возьму записи с косыми чертами и амперсандами и посмотрю, будет ли это иметь значение. Как примечание, DBF этого шейп-файла кодируется в UTF-8, который я также установил в геосервер. Может ли это иметь значение?
MWrenn

4
@MWrenn Я не уверен, поэтому не буду пытаться ответить, но экспорт данных в другой формат должен помочь определить, является ли проблема текущим хранилищем / форматом. Возможно, попробуйте открыть свой Shp в ArcMap или QGIS, ограничив область bbox вашего примера, а затем проверьте атрибуты содержащихся объектов - включают ли они какие-либо специальные символы, на которые может повлиять кодирование?
tomfumb

Ответы:


1

«Решение», которое я реализовал, состояло в том, чтобы импортировать шейп-файлы в базу данных postGIS с помощью shp2pqsql, который разрешал функции исчезающих точек при использовании фильтра CQL. Теперь я могу сделать точно такой же запрос фильтра CQL и увидеть все точки на всех уровнях масштабирования. Затем мне пришлось настроить несколько автоматических процессов для обновления базы данных postGIS вместо шейп-файлов, но это заняло всего несколько часов.

Я до сих пор не уверен в первопричине исчезновения точечных особенностей. Я пробовал разные проекции и средства записи шейп-файлов (QGis, ESRI, shapefile.py или pyShape или что-то еще) с одинаковым точным результатом каждый раз. Я не эксперт по геосерверу, поэтому не решаюсь назвать это ошибкой, и это, вероятно, что-то особенное в моей установке, но я смог воспроизвести на двух разных экземплярах, работающих на двух разных компьютерах геосервера, работающих под управлением 2.2 и 2.2. 1, оба в Windows (One Xp, на Server 2003).

Я также не могу публиковать исходные шейп-файлы, поэтому я думаю, что основная причина останется загадкой.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.