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

[Tyler Mitchell (OSGeo)]

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.

> (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.

> (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?).

> (4)     Start writing a draft specification document (maybe on the wiki)
> and a sample input file based on the list of elements from step 2.
> Remember that these two (2) documents are not the same thing.

Hopefully we can pick something already existing, but I will guess that
there will be some holes to fill as well.  I think we can develop a
simple schema fairly easily and use that as reference implementation.

I'd like to hear from a few more folks already dealing with specs too.

Mapnik particularly caught my attention since it meets most of my other
requirements for output files and styling at least.

> I think it might be helpful to have some code that we can use to start
> processing our sample input file to produce some type of output. Having
> some working prototype code will help us find problems with the input

Your simple examples ideas works well for me and we can even use our
agility to move it toward anything already existing :)

I'm all for simple prototypes with Python, though I don't think that
should discourage anyone.  Think of them more as unit tests ;-) .. with
the final implementations being done in whatever app can handle it.

Once we finish with specs and testing some scenarios we'll quickly get
into the more interesting arenas of complex data sources - hopefully we
can leave that for later :)

Thanks guys,
Tyler