[OSM-talk] The segments vs ways vs superways question again...

[80n]

Most of these data model issues come up from time to time on the list.
Usually there is a short heated debate and then everyone looses interest and
we all go back to doing the same old thing until the next time.

Are there any volunteers to form a working-party to a) catalog the current
data model deficiencies and b) prepare a well thought-out proposal for a
solution?

I don't mind us discussing it all again on this forum but I'd rather see
some concrete progress towards a solution.

Volunteers please?

80n


On 1/3/07, Jochen Topf <jochen at remote.org> wrote:
>
> On Wed, Jan 03, 2007 at 02:13:56PM +0100, bvh wrote:
> > I keep asking : what specific problems are you solving? and I am getting
> > very superficial answers from people who are making proposals that
> > would introduce a lot of work or even risk to set back the project.
>
> Ok, here are a few problems I have encountered. Some of them I have
> mentioned already. I don't say they can't be solved with the current data
> model, but at some point you have to ask yourself whether the fixes you
> can make are only hacks and whether a different data model couldn't
> solve the problem in a better way.
>
> And before I get to the list another important thought: Whatever we do,
> it has to be backwards compatible to the current data and reasonably
> easy to switch the software over. Otherwise it is not going to happen.
>
> Currently we can't do:
>
> - Areas with holes in them. Current hack around this: Define inner area
>   with higher layer. Disjoint areas: Say several parking lots around a
>   convention center that we want to tag together.
>
> - Road with tram line down the middle. Current hack around this: Define
>   two ways on top of each other (which makes them basically uneditable)
>   or use different slightly off-centered nodes which leads to bad
>   rendering.
>
> - Motorway. Current hack: Two ways, one for each direction. But now you
>   can't render the motorway correctly on all scales. On lower scales the
>   two ways will overlap, on larger scales they might be too far apart.
>   Now think what will happen if part of that motorway goes over a bridge.
>   You can only model this as two bridges by giving each of the motorway
>   directions a layer=1 attribute. If you want one bridge what are you
>   going to do?
>   On a even lower scale (say a national map) you might want to draw the
>   motorway network without proper motorway links, just draw the
> interchanges
>   as a single dot. You can't do this without hacks because you haven't
>   modelled the motorway correctly.
>
> - Automatic reordering or re-directioning of segments/ways is not
>   generally possible because there might be oneways or other features in
>   there which depend on the direction. This is not a problem with the
>   data model but with the way it is currently used. With the current
>   software it is obviously difficult for users to do this correctly.
>   I think this is in large part due to the issue with streets beeing
>   part way oneways and partly not, making it awkward to handle. Similar
>   for streets beeing part-way divided and part-way not. To make matters
>   worse we can't know which tags are dependent on the direction of a
>   segment and which are not, because everybody can invent tags himself.
>
> - Tagging longer collection of ways together: Lets say you have a
>   tourist route which consists of lots of different roads and together
>   they are the "Route du vin" or whatever. Currently you have to tag all
>   ways in this route with the extra "route=tourist" and "name=Route du
>   vin". Ups. Can't do that. "name=" is already taken for the individual
>   parts. Same goes for bus routes for instance.
>
> - Large rivers: On the one hand you want to model them as a way (for
>   instance to make them routable for ship routes and to be able to draw
>   the flow direction). On the other hand they are more like an area
>   because they tend to get narrower and wieder, open up to the sea etc.
>   Currently these aspects can both be modelled but as two distinct
>   features. There is no way to combine them. A similar thing happens
>   with nodes and areas like a nodes with a place name and the area this
>   place covers or a parking lot symbol and the area that parking lot
>   covers. They really should be connected in some way which allows
>   renderers to do the right thing at all scales, i.e. render as point on
>   on scale, as area on another.
>
> Ok, thats enought for now. :-)
>
> Jochen
> --
> Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/
>   +49-721-388298
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20070103/ed6eff1e/attachment.html>