[mapserver-dev] Expanding the MapServer Project

[Yewondwossen Assefa]

On 25/03/2011 9:47 AM, Daniel Morissette wrote:
> On 11-03-25 09:06 AM, Jeff McKenna wrote:
>> Before we move forward with this I'd like to hear the comments from all
>> of the PSC regarding TinyOWS and its database support (as far as I know
>> it still only supports PostGIS connections). Is there a plan for TinyOWS
>> to leverage OGR to connect to supported databases? For example, the ZOO
>> project uses OGR to connect to any OGR-supported database for MapServer
>> WFS-T connections (if you don't believe me, check it out yourself:
>> http://zoo-project.org/site/ZooWebSite/Demo/WFS-T)
>>
>> If MapServer adopts TinyOWS, am I correct to assume that OGR would be
>> leveraged for WFS-T connections?
>>
>
> (Sorry for the long response, I wanted to give more than just a yes/no 
> answer to explain my reasoning)
>
> You're right that ZOO implements WFS-T support via OGR, and I was 
> quite happy to see this last fall. At the time the WFS-T stuff was 
> wrapped in a WPS request (dunno if that changed yet), so it was not 
> really native WFS, and for anyone to adopt and use it in real life 
> that would be an important requirement in my opinion. I discussed this 
> with the ZOO guys last fall and they confirmed that it would be 
> possible (and relatively easy) to make a native WFS-T interface so 
> this is not a blocker in my opinion. Another point for ZOO is that it 
> reads its layer config info from mapfiles directly via libmapserver.so 
> (mapfile support was also added to TinyOWS at the sprint last week 
> using a custom parser).
>
> You are also right that TinyOWS supports only PostGIS, and actually it 
> is very tightly integrated with it, so OGR support in TinyOWS would 
> not be trivial.
>
> My opinion however is that being tightly connected to the DB is one of 
> TinyOWS' strengths and not a weakness. The WFS-T spec is better suited 
> for DB engines such as PostgreSQL, Oracle, etc. that support stuff 
> like concurrent transactions, locking, etc and are optimized to 
> support that.  OTOH, most of the OGR formats are read-only/write-only 
> and do not even support random update... and unless the format is a 
> DBMS under the hood then locking and concurrent update requests are 
> not supported and would result in data corruption. Yes, one could add 
> locks around the OGR calls in the WFS-T implementation for flat-file 
> formats (for the few that support random update), but as traffic 
> increases to more than a single user those locks would quickly become 
> a bottleneck.
>
> Unfortunately this means that WFS-T on top of OGR does not give you 
> support for all OGR formats (which would have been the main value that 
> I think you're looking for), it would work well only for DB engines 
> such as PostGIS, Oracle, a 2-3 others that are well suited for 
> transactions.
>
> So to answer your question about whether TinyOWS would eventually get 
> OGR support if it joined MapServer: I don't personally see this as a 
> short term plan for the reasons above. Without having looked into all 
> the details, I was more thinking that we should implement native DB 
> drivers directly in TinyOWS for Oracle and a few others that would be 
> optimized to get the most out of each DB's features in a transactional 
> context. It might turn out that OGR could offer that eventually (I 
> didn't check recently, Frank would be best to comment on that), but I 
> don't think generic OGR support is the next logical step of TinyOWS. 
> (Of course I'd love to be proven wrong since I love OGR and the 
> concept of a generic interface to avoid code duplication)
>
> I hope that information helps...
>
Hi All,

  I think in most cases that I have come across, the main thing I have 
seen is that people want to be able to "edit" their data through a web 
interface and are looking for a solution to do that. They certainly will 
use OpenLayers as their client tool and are looking for server side 
solutions. You have people with simple needs (kind of a red-lining) , 
simple shape files or complete spatial data base. Some are knowledgeable 
about the existence of a spec called WFS-T and some could care less what 
protocol is used, if it does the "editing".

In my case I always think first of using Tinoyows as server side 
component. This is because I know if works well, It is easy to install, 
plugs well with OpenLayers, use PostGis that I am familiar with. It 
becomes a no brainier.
But I wish sometime to also have a simple solution to do "editing" on 
shape files for example without a need for a database or just 
redlining/saving them to disk, that is "easy" to setup with the same 
kind of environment that I am used to deploy mapserver or tinyows.   
There are diffrent solutions to do that, and maybe Zoo fits this 
criteria (I have never used it, so please correct if am wrong).

if we strictly think in term of WFS-T transaction, It generally only 
make sense on Spatial DBs. If we think about "editing" and WFS-T as a 
common way of providing editing with OpenLayers, I think editing OGR 
supported formats definitely fits also in the picture.
What do we say now to people that want to edit their shape files and 
want to use the MapServer family products? We should be able at one 
point to explain that It is better to do editing on a spatial data base, 
but we also offer the possibility to do editing directly on files.  Is 
this not a need that other have seen?  If that is the case, It is 
releveant to discuss on how the MapServer family products can address 
this need without sending people to other tools.

best regards,



-- 
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: yassefa at dmsolutions.ca
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------