[OSM-dev] proposal to kill areas

[Lars Aronsson]

Nick Whitelegg wrote:

> > Sure, a full GIS system would use areas for administrative borders
> > and vegetation types, but I have no plans in the foreseeable
> > future to add that to OpenStreetMap.  Have you?
> 
> Yes! :-)

For administrative borders, or for what?  What are the basic 
operations you plan to provide for areas?  How do you get the 
data?  Is this for TIGER import, or do you walk along city borders 
and lake beaches with your GPS?

I see a lot of unresolved problems with "ways".  Under the 
assumption that OSM is just a throw-away factory where the entire 
focus is on gathering free data, I can live with these 
shortcomings.  But under the opposite assumption that we are now 
building the "ultimate map wiki", perhaps we need to address these 
issues, and maybe before the data model is extended with more 
exotic features:

* Ways can only hold a certain number of line segments.  I'm 
having problems creating really long ways, it doesn't seem to 
scale well.  Therefore, I have to create many small ways of, say, 
100 line segments each.  To find the real E4 motorway, you will 
have to add up dozens of smaller "ways" all having the same 
name="E4".

* It's not decided if a motorway, drawn with dual line segments in 
parallel, should be one way or two different (one-way) ones.

* While E18 runs all through Sweden (from Oslo to Stockholm), it 
is not a motorway all the way.  For some part, it coincides with 
E20.  I have not seen any guidelines for whether to create two
overlapping "ways" for E18 and E20, containing the same line 
segments, or to create a single way with name="E18, E20" there.
I usually do the latter, but I haven't investigated what others 
do.  Also, since ways must be short, I terminate the way every 
time the road type changes, making one with class="primary" and 
a new one with class="motorway".  Yes, I'm using "class" since I'm 
using the edit applet.  That's yet another inconsistency.

* The system seems to keep line segments within a way in the order 
they were stored, and this is good.  But there is no standardized 
way that line segments within a way should be ordered, so every 
user or client software can do it differently.  Good or bad?

* There is no method to insert a node in the middle of a line 
segment or to remove a node and join the two connecting line 
segments.  At least not in the edit applet, and probably not in 
the API.  I often find that a new connecting street or a new 
motorway exit has been tracked, so I need to branch away from an 
existing "way", and this calls for a new node in the middle of an 
existing line segment.  If I delete the line segment, create a new 
node and two new line segments, I also have to add the two new 
line segments to the way, but then they will not appear in the 
same position as the old line segment.  It is completely 
impractical to try to place them right, so I just ignore this.

* The API doesn't provide history and diff functions, which are 
essential to the wiki-ness of the application.  And it's not 
trivial to implement them, because nobody has any idea what 
they should look like for a mapping application.  The introduction 
of ways and areas are likely to complicate this further.  Does the 
server even record the edit history for ways?  How?


-- 
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se