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

[bvh]

On Wed, Jan 03, 2007 at 04:39:22PM +0100, Jochen Topf wrote:
> 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.

A client can easily order an unordered set of segments in two subsets:
those forming the exterior and those forming the holes. The datamodel
does not need to express that information.

> - 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.

I don't understand why having two segments on top of each other is
a hack? That editors don't cope with it  is a problem
in those editors and not in the datamodel.

> - 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.

A renderer can easily find out at what scale it is working and merge
two moterways if they are displayed too close to each other.

>   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?

I am not sure what the problem is here?

>   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.

Again I don't understand the problem here. It would be quite easy for
a program to drop one direction if it just wants to deal with the
network at a very high level.

> - 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

First define in which order you want them. Next say why you need them
in that order.

>   data model but with the way it is currently used. With the current
>   software it is obviously difficult for users to do this correctly.

That is why users should not have the burden of needing to reorder
segments. Introducing polylines btw _will_ put the burden of
ordering on the user.

>   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

Awkward to handle? How so? For whom, and when trying to fullfill what
purpose exactly?

> - 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.

Segments can be part of multiple ways. Just make the segments belong to
their 'normal' streets and also to the symbolic "route du vin".

> - 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.

Good point here. Though most of the proposals that heve been floated on
the list the last days didn't seem to adress this issue.

With some creative tagging the combination could easily be made
without making changes to the datamodel.
For example the node representing the center of a town could have
a tag city_area="37824" where 37824 is the id of the way that
represents the cityarea. Of course the editor should abstract this
away from the user so that he/she does not have to deal with the
id's directly but just has to click on the area.

cu bart