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

[stefan at binaervarianz.de]

On Fri, 26 Mar 2010 13:45:17 +0100, Klaus Dietrich <kl-di at gmx.de> wrote:
> am 26.03.2010 12:36, schrieb stefan at binaervarianz.de:
>> I heavily oppose that! Purposefully map something in a wrong place is
>> just
>> wrong in my opinion.
> Well, it's not purposefully wrong, but reasonably generalized. Besides,
> how would you map the landuse in the correct place? Map the axis of the
> road, then map the border of the left landuse, then the border of the
> right landuse? Or the axis and width of the road, then project the
> coordinates of the landuse? You end up with three nodes orthogonal to
> the axis.

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.

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

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

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

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


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

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

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