sfkeller at gmail.com
Tue May 6 22:39:08 BST 2008
Urging editors and converters to maintain direction constraints breaks
almost all implementations and makes it harder to implement.
There are simple ways like the encoding I proposed.
Think about what reading OSM areas currently means to
validators/converters/editors/renderers because of the
First they have to read in all(!) nodes into memory befor he can assemble
them to ways.
Second, they have to check (hopefully closed) way tags in order to find out,
if there is a tag which claims to be an area tag, which is eventually(!?)
documented in the wiki.
Third, they have to read in the whole(!) relationship section in order to
find out if there are eventually relationships which refer to areas.
I don't have a silver bullet for all way (= linestring) and area (= complex
and/or mult-polygon) encodings. But I get the impression that the current
encoding of OSM constatnly tries to avoid a simpler solution, may it be on
purpose or not
2008/5/6 Iván Sánchez Ortega <ivan at sanchezortega.es>:
> El Martes, 6 de Mayo de 2008, Martijn van Oosterhout escribió:
> > 2008/5/6 Karl Newman <siliconfiend at gmail.com>:
> > > [...] but we already have problems with mappers understanding the
> > > clockwise/counterclockwise rules;
> > What clockwise/counterclockwise rules?
> Namely, that the inner hulls (rings) of a multipolygon must have the
> direction of the outer hull (ring), or else some renderers will bork up
> result. See:
> Validators and automated tools can take care of that, though.
> Iván Sánchez Ortega <ivan at sanchezortega.es>
> Now listening to: Hevia - Tierra de Nadie (No Man's Land) (1999) -  La
> Línea Trazada (3:29) (85.363602%)
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev