[mapserver-users] OGR versus PostgreSQL and XML-Mapfiles?

[Stefan F. Keller]

Frank,

Frank Warmerdam wrote:

> Shapefiles have a lot going for them as far as being
> ubiquitous, easy to access  very efficiently, generally
> simple and a reasonable set of geometric types for  most
> GIS purposes. On the downside they lack internal metadata,
> coordinates  systems, and representation information. Also
> as you point out xbase is sucky in  a number of respects.
>
>> Aren't we the "parents" who can define ourselves what
>> is "native" 
>> to Mapserver?
> 
> Shapefiles are "native" because that is the mechanism that Steve has
> fine tuned  for maximally efficient access. Both OGR and PostGIS 
> access slower due to extra  layers of abstraction, and data 
> structure conversion going on (even OGR on  Shapefiles). We could 
> develope a new "native" format for MapServer that is as  fast as
> shapefiles, but what exactly would it offer that shapefiles don't? 
> ...

Simply put: That's all the advantages of a system-neutral XML-format which are
well summarized in the OGC presentation of GML. Specifically it's mainly the
*backend* you mentioned; but also this: 

A common well known "more universal" (XML) data structure would give more
possibilities as well as a fair chance to the free market for other GIS. This
will most probably result in more and better functionality of the GIS
supporting Mapserver as well of Mapserver itself. 

Therefore: Why not take GML 3 (zipped and/or indexed)?

>> So, what I still want to evaluate is, if a sequential (binary) 
>> file object stream to Mapserver (perhaps via OGR as zipped XML) 
>> is faster and more flexible in querying than a comparable 
>> (possibly indexed) object stream from PostgreSQL?
>
> Hmm. A bit hard to answer.
>

Let me explain: 

* I assume that a sequential file object stream (import online 
  via OGR) is faster (unindexed at least for a full zoom) 
  than an object stream from PostgreSQL (import offline 
  via PostgreSQL-Loader). 

* But for data analysis PostgreSQL would be more efficient 
  and of course more flexible than a file object stream.
  So, importing an XML file into PostgeSQL would provide
  both graphic (Mapserver) as well as data anylysis 
  (PostgeSQL) access with the same implementation effort.

That's my short-term performance/flexibility-dilemma!

Best regards,
- Stefan Keller