[mapserver-dev] GSoC Ideas for MapServer

[Rahkonen Jukka (MML)]

Hi,

Some quick comments about TinyOWS and Mapserver:

- I have been running TinyOWS on my personal server for some years and I like it just because it is so tiny. Even I have been able to compile it on Linux.
- Tiny things which are loaded with more ballast tend to get heavy. I think that TinyOWS has a right and reason to live as something feather-light.
- Speed is seldom the main sorrow with WFS but my opinion may change during next months because we are supposed to receive two million polygons as inserts through WFS-T (that's not the lean TinyOWS of mine). However, at the moment I consider that the biggest general issues are that one never knows what happens when queries contain advanced filters and making successful WFS-T requests for an unknown WFS server mark is pure black magic. I believe that the best WFS clients are analyzing with some heuristics from which server make the GetCapabilities is probably coming and adjust their behaviour accordingly which is not exactly how standards are supposed to work.
 - I am rather sure that no WFS server in the world really supports WFS versions 1.0.0 and 1.1.0 literally as written into the standards. It may be even impossible per se because specifications contain contradictory information but developers have also continued to support non-standard behaviour because they do not want to break existing applications. At least supporting both versions is difficult because there are some nasty differences. WFS versions 2.0.0, 2.0.2, and upcoming 1.1.1 will make all-version support even more difficult.
- If a GDAL/OGR based WFS-T server is on the wish list it might be worth considering to build such from the scratch and make it support only WFS >= 2.0.2 and no older versions at all. I mean, straight to the cutting edge without old weights made of lead.
- Trying to support other OGR sources than databases (PostGIS, Oracle, MSSQL, Spatialite, perhaps GeoPackage) for full WFS-T does not feel so important that it would pay to start struggling with reliable FID handling, stored queries and perhaps locking and versioning.

BTW, I am back from holidays and I have noticed and I appreciate your votes for my PSC seat.

-Jukka Rahkonen-

 
Even Rouault wrote:

Le vendredi 20 février 2015 23:24:40, Daniel Morissette a écrit :
> On 2015-02-20 4:21 PM, Oliver Courtin wrote:
> > Le 19 févr. 2015 à 15:35, Even Rouault a écrit :
> > 
> > Hi Even,
> > 
> >> I doubt the overhead introduced by OGR would be really significant 
> >> if you take into account the whole chain
> > 
> > I you have doubts, i have not :)
> > And this not because of OGR itself, but because of an abstraction 
> > layer in the middle. It would cost (mostly on big GetFeature requests).
> 
> My 0.02$:
> 
> While I can appreciate Olivier's design goals, I can also see the HUGE 
> value provided by OGR support in TinyOWS for lots of users, and doing 
> it with the help of libs such as GEOS is clearly feasible even if it 
> might result in a bridge of (slightly) inferior quality to the support 
> provided by the prime backends (PostGIS, Oracle SPatial and SQLite).
> 
> The challenge may be a bit big for a GSoC student, but I think we 
> shouldn't completely rule out the idea of supporting OGR in TinyOWS if 
> the right project and funding became available.

I can understand Olivier's worries too, and there might be indeed technical difficulties due to the abstraction that would hide a few things that might be needed.

Regarding ST_GeomFromGML(), OGR has OGR_G_CreateGeometryFromGML(), which coupled with OGR_G_ExportToWKB()/OGR_G_ExportToWKT() should please most backends.

Anyway, if other backends are added to TinyOWS, I guess that the code refactoring that would result of that work would at least make it a possible option (like the virtual table mechanism used for the various backends in MapServer). I guess that the abstraction that could result could look like the OGR abstraction. For WFS-T, you need GetNextFeature() (SELECT),
CreateFeature() (INSERT), SetFeature() (UPDATE), DeleteFeature() (DELETE),
GetFeatureCount() (SELECT COUNT(*) FROM), StartTransaction() (BEGIN) ...

I'd be curious if someone has measured the overhead of OGR use in MapServer when doing native shapefile/postgis/OCI/mssqlspatial(/SDE !) vs OGR shapefile/postgis/OCI/mssqlspatial(/SDE), for example in WFS.

Even

--
Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev