[OSM-talk] API v7
Frederik Ramm
frederik at remote.org
Tue Aug 19 00:32:24 BST 2008
Hi,
> Reoccurring problem 1: Way splitting.
True, problem exists. However the opposite (having ONE way for the whole
of a country-spanning motorway) is also undesirable.
> not splitting the ways and giving parts of them
> different properties with relations is not much better---there is no
> support for including parts of a way in a relation, so the relations
> will contain one way and (hopefully) two nodes
You could also have a relation encapsulating a part of the way (way,
from, to) and make THAT a member of another relation.
> Reoccurring problem 2: Two side of a coin, oops, a way. Most ways have
> two sides, often they are the same, but also often they are not.
True, problem exists (and I have a bad feeling about all those
"left/right" things).
Two further recurring problems are (3) areas and how to split them into
parts that can be handled (and how to know whether you're inside or
outside), and (4) related ways like "a footway runs in parallel to this
road, 25 metres from the left hand side".
> So far for the problems. Please discuss my view on the problems (above)
> independently from my ideas on solving them (below). Mixing discussions
> on problem and solution usually lead to nothing.
I find it slightly arrogant on your part to tell us in what way you
would like us to discuss your ideas and which kind of discussion you
believe leads to something and which doesn't. But I'll gloss over that
for now.
> Let's see how it changes with some additions:
>
> <way id="35" ...>
> <nd ref="1"/>
> <nd ref="22" p="P1"/>
> <nd ref="333" p="P2"/>
> <nd ref="4444"/>
I still don't see why you would need P1 and P2. You could have
<tag k="foo" v="bar" from="22" to="333" />
and it would work just as well.
Your whole proposal is surely one valid way to go. But I think the data
model is burdened enough as it is. Why ram ever more functionality into
the data model? We are already at the point where you need editors to
help you work with the data. Why should the user care whether segmented
tags as you describe them are actually stored as part of the way (which
will, by the way, incur a change to the whole way object whenever
something is changed even for a small part), or whether a new relation
object is created for every single segmented tag?
We're all too technical-thinking here I believe. The question is not how
we put things in the data model. The introduction of relations was
necessary to preserve integrity but now any complex constructs can be
built using relations, if one so desires. (I'm not saying we must not
change the data model at all, I'm just saying it is not the focus.)
The important question is not how we stuff things into XML or SQL. The
important question is how do we make these concepts available to the
user of the editor. And we're only starting. JOSM's user interface
requires too much knowledge about intricate details, and creating
segmented tags using relations is really impractical. But once we have a
good user interface, creating the necessary relations behind the scenes
would be easy. And for renderers and other users it would also be no
different in complexity whether we do one or the other.
> Q: Implementation or we're not interested.
>
> A: Sure, give me a SVN account and I'll change the server software. I'd
> also need an admin account for the main server. And YOU'LL take the
> blame that starting next week not a single client will be able to talk
> to the server, won't you?
This, again, is a bit harsh, as people *have* actually taken the server
and editor code in the past, created a working system on their own
machines, and presented it to OSM users to play with. You don't have use
the live system to build a proof of concept.
But as I said, I believe the problem is not the data model but the user
interface.
Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the talk
mailing list