[OSM-dev] proposal to kill areas
Lars Aronsson
lars at aronsson.se
Sat Jul 22 23:22:45 BST 2006
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
More information about the dev
mailing list