[mapserver-dev] GSoC Ideas for MapServer

[Even Rouault]

Le jeudi 19 février 2015 00:30:51, Oliver Courtin a écrit :
> Le 18 févr. 2015 à 17:17, Even Rouault a écrit :
> 
> Hi All,
> 
> >> I left an older idea which was inthe 2012 page: Spatialite support in
> >> TinyOWS. Olivier was listed as potential mentor for this idea, would you
> >> still be interested in mentoring this potential project if a student
> >> applies? If not then please feel free to remove the idea from the list.
> 
> Yes Daniel, still interested in,
> Thanks to keep this alive :)
> 
> > Actually I'm wondering if generic OGR support couldn't be targetted. And
> > spatialite would be just a particular case. Not all OGR drivers could be
> > fully supported, but those with native SQL capabilities could.
> 
> Really not sure about this Even,
> as with TinyOWS we really care about performances,
> having something in the middle (as OGR) will always be a loss.

I doubt the overhead introduced by OGR would be really significant if you take 
into account the whole chain (if performance was really a primary objective of 
WFS-T, they wouldn't have used XML encoding ;-)). The interest would be 
essentially if you want to support many backends with minimal coding on 
TinyOWS side.

> 
> And we need a full FE support to handle a new spatial database,
> so really not easy to be done in a generic way.

Indeed FE might require some knowledge about driver capabilities to be able to 
produce the appropriate variant of SQL, especially regarding spatial operators 
(although most should have ISO or ISO-like syntax). But hopefully most FE -> 
SQL translation could be driver agnostic.

> 
> 
> 
> 
> 
> 
> 
> And to be clear the real target is not primarily SpatiaLite
> The real target is Oracle Spatial support.
> 
> Till now most of our clients already used PostGIS,
> and those who used Oracle Spatial preferred migrate to PostGIS or use FDW
> to replicate rather than fund Oracle native support in TinyOWS.
> So we really ask ourself if this feature is really a need or not…
> 
> 
> 
> 
> 
> Full WFS 2.0, or Complex Features handling,
> on the other way is clearly much more interesting for end users, for
> example… (but i guess too big to be a the target for a GSoC)

Complex features is a complex subject even outside the context of a GSoC...

WFS 2.0 would be more reachable. And could be done step by step as there are 
several compliance levels.

> 
> 
> O.
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com