XML Mapfiles... are we looking to far?
Tom.Kralidis at EC.GC.CA
Wed Jul 19 13:25:36 EDT 2006
WMC can handle a lot of the layer block info, but there are bits of the
mapfile which aren't covered (imagetype, imagecolor, reference, legend,
Maybe a new mapfile schema can incorporate already defined bits and put
MapServer-specific stuff into it's own namespace. Before we go out and
define yet another language
, we should see what's out there already and come up with a skeleton.
Right away I can see OGC:WMC or the forthcoming OGC:OWSContext, as well
as the OWS Common schemas, as building blocks.
> -----Original Message-----
> From: UMN MapServer Developers List
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Sean Gillies
> Sent: Wednesday, July 19, 2006 1:07 PM
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-DEV] XML Mapfiles... are we
> looking to far?
> Keep this in mind: every time someone creates a new XML
> language, God
> kills a kitten.
> Yes, I used to advocate a bit for an XML config, but anymore I think
> that somebody ought to just write some XSL that converts web map
> context + OGR virtual files to a mapfile.
> On Jul 19, 2006, at 10:40 AM, Tamas Szekeres wrote:
> > Hi,
> > There is no doubt about the usability and the wide audience of the
> > XML/XSL technology in general. However in the mapserver's
> > it's just another format to persist the map configuration. At the
> > developer's perspective another parser and writer is to be
> > implemented. The parsed xml document object is to be immediately
> > translated into the mapserver structures that can be handled
> > regularly. If one would extend the schema at least the internal
> > structures and conversion method should be modifyed
> accordingly, not
> > easier than with the current implementation.
> > At the user's perspective if the configuration is generated
> > automatically using xml and xsl configuration templates
> creating xml
> > or text base output seems to be equivalent in complexity.
> > If the user creates the configuration by hand using xml is slightly
> > more benefical due to the high number of the tools for
> editing the xml
> > files. However in the mapserver's case making sure the file is
> > syntactically correct is not too much. One would like to see the
> > generated map immediately using a WYSWYG tool, so mapserver
> will come
> > into the picture and ensures the validation of that file by the way.
> > However in my opinion it would be benefical to provide support for
> > multiple configuration formats in a provider based fashion
> > by compilation switches. It would be crucial to retain the
> > compatibility with the existing map file format, and the user could
> > decide to include a provider and all of the dependent libraries on
> > demand. This approach could support the conversation between theese
> > formats easily.
> > Besides the file based configurations we should also consider to
> > support other location types to read and write the
> configuration data.
> > Tamas
> > 2006/7/18, Julien, Heryk <hjulien at nrcan.gc.ca>:
> >> Hi Tamas,
> >> I think there are many advantages in using xml. First, XML files
> >> are easy=
> > to
> >> create and schema validation can check document structure while
> >> you are
> >> writing it. Schema aware editors can also give you hints and do
> >> automatic
> >> inputs of required tags while writing mapfile document.
> Yes Mapserver
> >> validates mapfiles, but I think the addition of a mapfile structure
> >> validator like xsd would facilitate mapfile creation and debugging.
> >> Schemas can help newbie's to create there first config files and
> >> advanced
> >> users and developers visualise, communicate and work on the
> >> current mapfi=
> > le
> >> format. I also think that it would be easier to extend the mapfile
> >> struct=
> > ure
> >> in future Mapserver versions if we where using an xml format...
> >> for examp=
> > le
> >> adding new OGC tags to mapfiles would be very easy.
> >> Plus with all the new xml editing tools out there, schema
> >> visualisation and validation has become a child's play
> (hmmm.... well
> >> almost!).
> >> Just as you said earlier, automating map config creation would be
> >> another
> >> great benefit. And if Mapserver could read non static mapfiles
> >> (via URL's=
> > ),
> >> xml would be a great way to create dynamically generated mapfiles.
> >> If we
> >> consider mapfiles as being a kind of database (or database
> >> wouldn't it be great to be able to easily process it on the fly?
> >> XML coup=
> > led
> >> with xsl, xpath and databases would be one great way to do that
> >> kind of
> >> manipulation. A little like OGC WMC layers that are pointing to
> >> different
> >> data layers (wms layers), we could have dynamically generated
> >> mapfiles
> >> instead of one huge static file containing all data layers.
> >> Xml being rapidly more and more widespread, ways for developers to
> >> input
> >> serialization data into Mapserver would be much greater
> and flexible.
> >> Mapfile management would be more open and greatly enhanced with
> >> the use o=
> > f
> >> xml. For example a url fetched xml mapfile would enable us to
> >> easily modi=
> > fy
> >> a mapfile service according to certain parameter like language. We
> >> could
> >> thus have an automated multilingual mapfile. Currently we have to
> >> save a
> >> static mapfile for every language. They all point to the
> same data
> >> but
> >> containing language specific titles and metadata.
> >> Being an OGC fan, I think there decision to use xml to disseminate
> >> data a=
> > nd
> >> ease interop has been a good choice. In that same line of thought,
> >> I thin=
> > k
> >> an xml mapfiles format to serialize Mapserver would be a logical
> >> next ste=
> > p.
> >> Cheers
> >> H=E9ryk
> >> _____________________________
> >> H=E9ryk Julien
> >> Research Officer
> >> Natural Resources Canada
> >> 490 rue de la Couronne
> >> Qu=E9bec, Canada
> Sean Gillies
More information about the mapserver-dev