-
-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raster WMS-T with OGR tileindex not implementing filter translation support correctly? #5218
Comments
What does the layer definition look like? |
|
I hope this helps, the datasource is a View in Spatialite. |
Ah, good. I didn't see anything in the layer definitions that worried me. I'll see if I can make the warning more relevant - only throw it if there is a real need. |
@sdlime: when is it safe to ignore this warning ? |
Having build mapserver from latest master two days ago, the above posted warning became true, mapserver doesn't filter against time-value from getmap-request anymore. original error message: |
@rouault I'm using a SpatialiteView as Tile- and Timeindex for a WMS with aerial images and time Support. A workaround solution for me is to let mapserver not "look" directly in the spatialite-DB (as in my mapfile post above), but establish the db-connection via OGR/VRT. The only difference is the move of the SQL-Statement from mapfile to the vrt-file. Then mapserver does exactly what it should do - filtering against timeitem-field with time-parameter from getmaprequest. --> I argue, that there's something wrong/different with the spatialite implementation in mapserver. From my point of view it behaves different than generic OGR. I'm using latest GDAL/OGR 2.1.1 |
Another hint/Approach: doing the table-join directly in mapfile DATA-element (which was done in the spatialite-View) this also works well, but getting the log-entry: |
It would help if you could provide a
The "msOGRFileWhichShapes(): unsetting native_string" warning may appear if the view is not registered as a spatial view. This should normally not result in a misbehaviour (except potential bugs in the implementation...), but in client-side only filtering. |
Hi, Sincerely / Benjamin Schepers Luftbild und Geoinformationssysteme [cid:image001.jpg@01D1E97E.D3A593D0] Die Regionaldirektorin Postfach 10 32 64 Steuernummer: RVR 112/5797/0116 Diese E-Mail koennte vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. It would help if you could provide a
The "msOGRFileWhichShapes(): unsetting native_string" warning may appear if the view is not registered as a spatial view. This should normally not result in a misbehaviour (except potential bugs in the implementation...), but in client-side only filtering. — |
Hi, thanks for your Response. The Spatial View was build in QGIS DB-Manager SQL-Window - it's just a simple join of two tables, one with geom and some string/time-formatting operations: INSERT INTO views_geometry_columns It works well in QGIS and did in mapserver 6.4, Problems began with mapserver 7 this year.
The first doesn't work (view) - errorlog: The second one (mapfile JOIN) works - exactly the same request: the only abnormal thing in log is the warning 'unsetting native_string' maybe I did something wrong with the view? got it from https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/sp-view.html with my last build from mapserver from April / May (before the huge Spatialite-Code-changes) method one also worked, but with warnings: THX |
I didn't get your .db. I've pushed something that might fix your issue. |
According to
http://osgeo-org.1560.x6.nabble.com/Raster-WMS-T-with-OGR-tileindex-not-implementing-filter-translation-support-td5225415.html
I get similar logs.
I use "Spatialite" as OGR datasource for my time-/tileindex. The service works well and also the time values ar properly evaluated. But for each request I get an errorlog:
LayerDefaultTranslateFilter(): General error message. This data driver does not implement filter translation support.
Maybe this relates to
http://mapserver.org/development/rfc/ms-rfc-91.html
and the way, how the wms_time-logic evaluates time-values from ogr-datasources?
The text was updated successfully, but these errors were encountered: