On Fri, 26 Mar 2010 13:45:17 +0100, Klaus Dietrich <[email protected]> wrote: > am 26.03.2010 12:36, schrieb [email protected]: >> 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 _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
