[josm-dev] landuse near roads (WAS: self-intersecting ways)

[Klaus Dietrich]

Let's conclude this discussion here. Thank's all for your input, I'll
think about it and let's agree for now that on the long run we won't get
away without highway areas.

am 26.03.2010 15:36, schrieb stefan at binaervarianz.de:
> I'm not sure I can follow you here. I would normally map a road as the axis
> than draw the landuse border (or most of the time change the landuse
> border)
> with the distance to the road axis as observed in the wild. I would end up
> with three distinct ways with nodes each.
Yes, that's what i meant. Also see below.

>>> Points and shapes are defined by coordinates, not by there relation to
>>> other nodes or ways.
>> Sure, in the database, but is the landuse really defined with its own
>> coordinates?
> 
> Is anything not defined by its own coordinates? I don't see the point in
> making any difference here.
I thought may be the landuse is defined as being next to the road on one
side (which of course is an area in real life). But having looked at the
Flurkarte, I think you're right: there's one area for the landuse and
one *area* for the road sharing the same nodes.

>>> You can't rely on the renderer to expand the road and correct your
>>> misplaced landuse.
>> You have to, thats generalization and it's necessary for any map with a
>> scale lesser than say 1:5000.
> 
> 'Scales' belong to paper maps. Generalization was a must back then.
> Digital map data has no scale. A renderer may produce an image with a
> scale, but the generalization is then part of the renderer, not of the map
> data.
> 'Don't map for the renderer' is one of the basic principles in OSM. Let the
> renderer evolve, don't change the data for it.
I didn't think of it as mapping for the renderer but as generalization
at the time of survey to not make things complicated (for me). This
means I don't have to measure the road width exactly and make sure the
landuse has the correct distance. I'm satisfied with knowing "there we
have landuse=residential next to the road."

>>> What's the logic for mapping then? I map to the border of the landuse if
>>> it
>>> stands on its on, but to the next road if there is any?
>> Yes.
> 
> Ew.
Another more general description would be: map to the feature next to
the landuse or to the real border of the landuse if there is nothing
(mapped) next to it.

>>> What if the road gets deleted or moved? Should the landuse be moved
> also?
>> You mean if the physical road changes? Of course. It has to be re-mapped
>> then.
>> If the road still exists and the way is deleted it's an error and the
>> way should be restored. If the way must be moved because it was not
>> precise you simply move it and it stays correct. Whereas with your
>> approach you would have to move 3 different nodes at once which becomes
>> a problem in bends, because the radius changes.
>> I've often seen roughly mapped forest (landsat, ~20m maximum precision
>> with calibration) next to a road. Now someone moves the road in
>> direction of the forest because it was imprecise, but does not move the
>> forest. You now have forest to both sides of the road, which is really
>> wrong.
>> Had both been glued together it would still be correct.
> 
> I know the problem you describe here. And I acknowledge that it is more
> work to move all the nodes.
> But all those borders can have a very different level of accuracy and I
> would like to leave each of them to be changed seperatly.
> Just because I know (through a GPS track) where a road was, I don't
> necessarily have paid attention to the landuse around it.
> So I may correct the road, but I would leave it to someone with more
> knowledge to change the landuse borders around.
> Maybe they were far more accurate then the road? Who knows?
OK.

>>> Wherever I've seen landuse mapped near a road, it was mapped to its
>>> physical extends, leaving free space to the single way defining the
>>> center line of the road.
>>> If anyone decides to map the road as an area later, he don't have to
>>> touch the landuse.
>> That's a point though, but we're very far from that.
> 
> Maybe it's because someone said "we need this generalization" and "routings
> tools / renderers don't know what to do with it".
> I'm not a friend of doing something wrong just to have a convenient and
> fast solution. In my work this would be called
> a 'hack' and it usually explodes in your face half a year later.
Maybe it's because someone said "we don't need this degree of precision,
so let's just use a way".

>>> Or take the practical approach: If you are standing on asphalt, but your
>>> maps says you're standing on grass, who is wrong?
>> They are both right, but you are using the wrong map for the task. You
>> either need a map with generalization or you shouldn't demand such a
>> high precision. Remember, we are using comsumer-grade GPS. Precision
>> higher than say 3m will require high effort with these devices.
> 
> Again: there is no such thing as 'the wrong map' regarding the data.
> You probably still think in paper map schemes.
> OSM can be *the* map. Limitations are due to the tools that are used to
> create/render/use the map, but
> not the data itself. No need to introduce limitations there purposefully.
> 
> And the tools are getting better by the day. A colleague of mine works on
> (consumer) devices which combine GPS, WIFI/GSM and an accelerometer.
> These things can reach an accuracy of up to 1cm. And the hardware you need
> comes in any modern mobile phone.
> I'm looking forward on taking a laser range finder with me for mapping to
> get the size of buildings and the with of streets more accurate.
> 
>>> Undefinied (e.g. empty space) is far better that blatant wrong.
>> Right.
> So why then don't keep the free space?
See above.

>>> Sorry to hijack this thread, but I just had to comment this.
>> Same for me.
> I moved this to another topic. Actually this has nothing to do with JOSM
> either. The talk page here
> http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/highway
> would be the right place. But this discussion would possibly flood it.
> 
> I actually (think that I) know were we differ in our perception of a map.
> For me it is an artificial image of the real world, for you it is a source
> of information about the real world.
> While for me creating a map is a conceptional easy  task of 1to1 digitizing
> coordinates, for you it is about how to represent certain kinds of
> information.
Yes, thats true. As you said I probably still think too much of paper
maps, where it is all about a more or less precise representation of the
world without the claim for absolute completeness/correctness.

> This leaves you with a degree of freedom I don't have. You may find it
> acceptable to violate the placement of a border to deliver a vital
> information (what lies next to the border).
Exactly. I think as long as there is no absolutely binding definition
for each tag, a certain freedom is necessary.

> I don't. For me the extraction of information is a completely separate task
> another tool may perform on the collected data. And I fear that tailoring
> the data to represent certain kinds of information better
> will limit the possibilities of what other tools may be able to extract.
> 
> So, that was long enough,
> 
> Stefan