Rv: [Carto] Four Steps to Moving Forward With a Spec, Input File, and Working Map Rendering Engine Prototype

[Carlos Gabriel Asato]

________________________________
De: Tyler Mitchell (OSGeo) <tmitchell at osgeo.org>
Para: Landon Blake <lblake at ksninc.com>
CC: carto at lists.osgeo.org
Enviado: jueves, 8 de abril, 2010 19:25:51
Asunto: Re: [Carto] Four Steps to Moving Forward With a Spec, Input File, and Working Map Rendering Engine Prototype

Landon Blake wrote:
> (1)     Decide if we will separate layout information (like page size,
> margins, graphical components, inset map info) and styling information
> (label font, label size, stroke color, fill patterns). I think this
> separation is a good idea.

I think it is a good idea as well, since various apps will or will not
support different components already.  Mixing them all up together may
make it more difficult to incrementally support the standards.

*********************
I think this approach has an special advantage if you think in terms of a system with a cartographic library management system. Let's try to see an example:

Suppose that  you have a specific data source and you want to create creating different maps with different styles, layouts. Or declare different data source for the same map layout, layer arrange, display methods, etc.

DataSourceA with MapFrameA, MapDefinitionD, LayerRepresentationZ, GridJ

Same data source can be display in a different way

DataSourceA with MapFrameA, MapDefinitionH, LayerRepresentationT, GridM

In other way if you manage those map elements separately you also can do this

DataSourceA with MapFrameA, MapDefinitionD, LayerRepresentationZ, GridJ
DataSourceB with MapFrameA, MapDefinitionD, LayerRepresentationZ, GridJ
DataSourceC with MapFrameA, MapDefinitionD, LayerRepresentationZ, GridJ

That is something that works very well when you have to deal with hundreds maps because this process facilitates the re-use of map elements. But sometimes is much easier to have everything in only one file specially when you have to work with simple maps.

GA
*********************

> (2)     Decide on a list of elements or items that we want to support
> for both the layout and style components of the specification.

>From my brief discussions with a few others a while ago, I understood
that SLD was not robust enough to handle all the styling requirements.
I'd like to hear more on this.  What are other developers doing already?
I don't hear of any of them basing their styling on an OGC spec, so I
have to assume it's not designed for our (non-web) need.

*********************
I am not sure but we probably can extend SLD. 

GA
*********************

> (3)     Decide on a file format that will be consumed by map rendering
> engines that support or spec. This could be XML, plain text, YAML or
> something else. No need to have a flame war about the file format, we
> just need to pick something.

I think XML is the only choice ;-)  Well, I could be convinced otherwise
:)  My reasoning is that at least we can lower the barrier to entry by
allowing some projects to simply transform XML over to our schema.  I
might be dreaming, but something like a map configuration or desktop app
project file in XML could at least be transformed to handle the STYLE
side of things.  I think this is how QGIS's Mapserver export works (or
is the plugin?).

*********************

I also think XML is the best choice


GA
*********************

My best wishes

 Gabriel Asato
Unidad Sensores Remotos y SIG
Servicio Geológico Minero Argentino
(SEGEMAR)
Av. Julio A. Roca 651 p 8 of 1
Cdad. Autónoma de Buenos Aires
ARGENTINA

tel 54-11-4349-3158/26
fax 54-11-4349-3287


________________________________

Encontra las mejores recetas con Yahoo! Cocina. 
http://ar.mujer.yahoo.com/cocina/


      Yahoo! Cocina

Encontra las mejores recetas con Yahoo! Cocina.


http://ar.mujer.yahoo.com/cocina/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/carto/attachments/20100409/064356ae/attachment.html