[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