<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">De:</span></b> Tyler Mitchell (OSGeo) <tmitchell@osgeo.org><br><b><span style="font-weight: bold;">Para:</span></b> Landon Blake <lblake@ksninc.com><br><b><span style="font-weight: bold;">CC:</span></b> carto@lists.osgeo.org<br><b><span style="font-weight: bold;">Enviado:</span></b> jueves, 8 de abril, 2010 19:25:51<br><b><span style="font-weight:
bold;">Asunto:</span></b> Re: [Carto] Four Steps to Moving Forward With a Spec, Input File, and Working Map Rendering Engine Prototype<br></font><br>Landon Blake wrote:<br>> (1) Decide if we will separate layout
information (like page size,<br>> margins, graphical components, inset map info) and styling information<br>> (label font, label size, stroke color, fill patterns). I think this<br>> separation is a good idea.<br><br>I think it is a good idea as well, since various apps will or will not<br>support different components already. Mixing them all up together may<br>make it more difficult to incrementally support the standards.<br><br>*********************<br>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:<br><br>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.<br><br>DataSourceA with MapFrameA, MapDefinitionD, LayerRepresentationZ, GridJ<br><br>Same data source
can be display
in a different way<br><br>DataSourceA with MapFrameA, MapDefinitionH, LayerRepresentationT, GridM<br><br>In other way if you manage those map elements separately you also can do this<br><br>DataSourceA with MapFrameA, MapDefinitionD, LayerRepresentationZ, GridJ<br>DataSourceB with MapFrameA, MapDefinitionD, LayerRepresentationZ, GridJ<br>DataSourceC with MapFrameA, MapDefinitionD, LayerRepresentationZ, GridJ<br><br>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.<br><br>GA<br>*********************<br><br>> (2) Decide on a list of elements or items that we want to support<br>> for both the layout and style components of the specification.<br><br>>From my brief discussions with a few others a while ago, I understood<br>that SLD
was not robust
enough to handle all the styling requirements.<br>I'd like to hear more on this. What are other developers doing already?<br> I don't hear of any of them basing their styling on an OGC spec, so I<br>have to assume it's not designed for our (non-web) need.<br><br>*********************<br>I am not sure but we probably can extend SLD. <br><br>GA<br>*********************<br><br>> (3) Decide on a file format that will be consumed by map rendering<br>> engines that support or spec. This could be XML, plain text, YAML or<br>> something else. No need to have a flame war about the file format, we<br>> just need to pick something.<br><br>I think XML is the only choice ;-) Well, I could be convinced otherwise<br>:) My reasoning is that at least we can lower the barrier to entry by<br>allowing some projects to simply transform XML over to our schema. I<br>might be dreaming, but something like a map configuration or
desktop app<br>project file in XML could at least
be transformed to handle the STYLE<br>side of things. I think this is how QGIS's Mapserver export works (or<br>is the plugin?).<br><br>*********************<br><br>I also think XML is the best choice<br><br><br>GA<br>*********************<br><br>My best wishes<br><div> </div>Gabriel Asato<br>Unidad Sensores Remotos y SIG<br>Servicio Geológico Minero Argentino<br>(SEGEMAR)<br>Av. Julio A. Roca 651 p 8 of 1<br>Cdad. Autónoma de Buenos Aires<br>ARGENTINA<br><br>tel 54-11-4349-3158/26<br>fax 54-11-4349-3287<div><br></div><br></div></div></div>
</div><br>
<hr size="1"><br><font size="-2" face="Verdana">Encontra las mejores recetas con Yahoo! Cocina.
<br><span>
<a target="_blank" href="http://ar.mujer.yahoo.com/cocina/">http://ar.mujer.yahoo.com/cocina/</a></span></font></div></div></div>
</div><br>
<hr size=1><br><font face="Verdana" size="-2">Encontra las mejores recetas con Yahoo! Cocina.
<br>
http://ar.mujer.yahoo.com/cocina/</font></body></html>