[OSM-dev] dropping segments

Nigel Magnay nigel.magnay at gmail.com
Sat Jul 28 11:25:11 BST 2007


(resent 'cos the .gif was actually a .bmp :( )


> There is a problem with very large areas/ways. These cause major
> issues with the API/clients (editors). There was recently a large
> number of ways that were split due to them being to large. I can't
> remember the threshold for the number of segments per way that should
> be the maximum. There are some lakes that are multiple ways for example.


Isn't that only a problem because the current API only fetches a window onto
some data, rather than (say) "the entire way of all ways intersecting with
this bbox".

In any case, I think we have to be careful not to mix up problems with APIs
in deciding what we're logically trying to represent. I'd expect another
discussion around what API calls and behaviours make sense following on from
this, and what restrictions those calls might make (for example, it could
reject calls that caused an area to not be a closed path).


> > 2) Areas with 'holes' could be stored as an area with 2 child
> > areas, and appropriate tags on those areas to control which was the
> > bit being added and which was the bit being subtracted (the hole) -
> > (I hope that makes sense)
>
> Why can't layers be used for holes in an area?


I hadn't considered layers - sounds a possibility. I don't even know if
'areas with holes' are really needed - the only examples I can think of are
maybe donut-shaped parks? In any case, layers sound highly useful anyway,
for several reasons like :

1) We could separate out layers to have areas like "country outlines",
"county outlines"
2) We could have separate layers for 'temporary' data (such as the flooding
information I think has already been mentioned)
3) You could export these layers into planet.osm files separately -
unchanged layers wouldn't even have to be exported again at all...

 I've updated an example model to include one way to represent layers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070728/1263edba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after.gif
Type: image/gif
Size: 11615 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070728/1263edba/attachment.gif>


More information about the dev mailing list