OpenStreetMap

Making OSM data mor compact

Posted by Natureshadow on 23 June 2013 in English (English)

Right now, I am trying to reduce data in the region I currently reside in. There is lots of different landuse around here, and the borders of these areas are often duplicated, so that there is approx. 1m of void between the areas. I have started to unite these borders by merging nodes, so that data load on mobile devices (that use OSM data rather than Mapnik tiles) is reduced and the map looks cleaner. After all, there is no such thing as void in the real world out there ...

Furthermore, what was mapped here is unlogical: In the real world, there is a track, and on the one side there is farmland and on the other side there is a meadow. What was done is: Create two areas for the landuse by drawing them on a Bing background, leaving approx. 1m of void in between, then draw the track by following GPS data. Now the way crosses the farmland, which, in the real world, it doesn't - it's right in between the two areas, so the areas and the way should share nodes.

I just killed more than 100 nodes by merging them in a logical way, while not loosing any map detail. Why was that map pollution necessary?

Location: Hof Waldeck, Roßbach (Westerwald), Hachenburg, Westerwaldkreis, Rhineland-Palatinate, 56271, Germany, European Union

Comment from Pink Duck on 23 June 2013 at 10:52

Does the farmland and meadow actually meet and overlap the track though? Doesn’t merging nodes obscure the separation of ways useful for later editing selections?

Hide this comment

Comment from iandees on 23 June 2013 at 12:37

Removing data simply because you think it takes up too much space is "mapping for the renderer" and we don't want to do that. Make the data accurate and post-process it if you feel it's taking up too much space.

Hide this comment

Comment from smsm1 on 23 June 2013 at 13:15

I hate landuse areas that are sharing nodes with other areas, as they are a nightmare to try and edit, as the editors, yes even JOSM have not yet found a good way to choose the object selected at the mouse click.

Hide this comment

Comment from Vclaw on 23 June 2013 at 13:34

Landuse areas should not (usually) share nodes with roads, tracks, paths etc. The way for a road represents the centre line of the road.

So if the road shares nodes with a field, then you are saying the field goes halfway across the road. If you have a field on one side of the road, and a forest on the other, then there is a gap in between them. The road does have the width, even if it is only mapped as a way.

Though if you have farmland with a meadow right next to it, nothing in between, then they probably should share nodes.

Hide this comment

Comment from compdude on 23 June 2013 at 20:35

I agree that it's not always best to have an area share nodes with a way for a road. The biggest reason is that it's harder to select what you want when you're editing the map, and so it's a nightmare to edit, as mentioned by others. The only time I have areas share the same node as a way is when I'm mapping parking lots. In that case I do want the parking lot to be attached to the road going into and through the parking lot.

Hide this comment

Comment from Pan on 24 June 2013 at 03:11

For landuses next to each other, we should use relations in my opinion.

Hide this comment

Comment from Vincent de Phily on 24 June 2013 at 10:45

The biggest reason not to share nodes between a way and an area is that it is geometrically incorrect, because the landuse doesn't extend to the middle of the track. If the track is to be considered part of the landuse, then it should be included completely. Difficulty to edit and size of the download are valid but fleeting reasons.

See this help.o.o question.

Hide this comment

Comment from Sundance on 24 June 2013 at 20:45

I would agree with Vincent, a street isn't a field. By all means nodes should be shared when they are adjacent to each other.

While not correct the US state of Georgia imported roads they assigned a tag usgs-lulc:class=Transportion Communication (I'm guessing it was a typo of transportation), I sort of like it that way. Perhaps there should be a landuse=highway?

FYI: Railways are defined in the wiki as landuse=railway

As well a pet peeve of mine is the Canvec import where the forest areas overlap the highway, in most cases unless the canopy of trees is above the road there is a gap between the two.

Hide this comment

Comment from Pieren on 25 June 2013 at 12:18

For all crying about incorrect mapping, when we represent the road with a simple thin line, it's also a simplification of the real world and is also "geometrically" incorrect. So either draw everything as polygons or accept that some of the representations in OSM are simplified. Here the OP says that the landuse is at one meter from the centre line of the road, which is also probably incorrect (suggesting that the road is 2m wide, includ. shoulders). Even worst, the road is converted from a GPS trace and is overlapping some of the landuse because the second contributor did not conflate his data with the existing ones. So for all people stoping the landuse few metres before the highway centre line, I would ask them to draw the road polygons as well (there is a tag for that, check the wiki). If you want to be accurate, do it everywhere.

Hide this comment

Comment from Natureshadow on 25 June 2013 at 12:24

The argument about editors making it difficult to select a way when sharing nodes is valid.

However, concerning accuracy: Having landuse and the road share nodes and overlapping is probably even more accurate than any other proposal, looking at the inaccuracy of most civil GPS units and aerial imagery. OSM is not created with highly specialized tools that provide measurement in the dimension of a centimetre, so mappers should find a good trade-off between accuracy and practibility.

I have stopped merging nodes, anyway, because editing ways afterwards really is a mess.

Hide this comment

Comment from dcp on 25 June 2013 at 16:46

Doesn't anybody read the relation:multipolygon instruction page.

http://wiki.openstreetmap.org/wiki/Relation:multipolygon

Here is an extract:

==== Usage

The intended use of multipolygons is this:

Tags describing the multipolygon (e.g., landuse=forest) should go on the relation. The outer way(s) should be left untagged, unless they describe something in their own right. For example, a forest could be delineated by four roads, in which case the four ways would be tagged with the highway tag, but could still be used as "outer" members of the forest relation.

==== End extract

This clearly states that the outer perimeter of a multipolygon can share its nodes (i.e. they are merge) with roads. Therefore, in this case, at least half of the road on which the road runs is defined as landuse=forest.

Surely we should expect the renderers to understand this and act accordingly and this they do very well.

I have no difficulty editing such geometrical contructions. The difficulty lies in correcting the poorly documentated data usually entered by newbies using Potlach.

Hide this comment

Comment from cracklinrain on 27 June 2013 at 13:49

@dcp: I tested this method some weeks ago and liked it very much. It is very nice displayed using JOSM (For example the colouring of the areas or the list of relations in which the way is a part are named after the landuse type). It may take a little more time to click around in the menus to create a relation, but afterwards you have got some benefit from cutting the ways into smaller pieces - instead of re-drawing them.

Until now I did not try to include the street-ways, but my first results are nice. What stoped me from trying this was that it is the next step to using relations for really everything. So if you cut the streets along the landuse you gonna have many tiny pieces of ways. Those should be included into a relations, too.

I remain undecided for the first.

@smsm1: A mapper told me that there is a key at Potlach which enables the mapper to choosebetween the swapping areas. I think it was "#".

@Natureshadow: I am a friend of tidying up the map. There is so many stuff which is not mapped in a satisfactory way concerning landuse that I started a discussion at the wiki. So I think I understand your reasons very well. I am against the idea that streets are allowed to share a node with anything unrelated, because it complicates stuff in many cases. O does not fit into the further mapping.

@all: You can read a lot about mapping landuse, but we should really have a proposal which describes the most accepted mapping-technics. This would enable us to improve our mapping technics and to avoid discussing about this again and again.

Hide this comment

Comment from dieterdreist on 4 July 2013 at 10:15

Please don't unify adjacent landuses, when there is a gap in between them i.e. the gap is there in reality because there is a way or path or scrub, a waterway, sand or something else that isn't a field in the case of landuse=farmland). You are removing details that convey information. The landuses should share nodes if the have a common border (or better use multipolygons in case the shared way has more than very few nodes).

IMHO streets should not have a landuse (or should have an explicit street-landuse). This is also how reality deals with this: streets are not part of the parcel land, they are usually land that is not part of a parcel.

Hide this comment

Comment from dieterdreist on 4 July 2013 at 10:18

areas should not share nodes with highways, because the highway is representing the center of the road, and its borders are only implicit (add half the width to the center line), while areas are drawn at their real limits, so they shouldn't have common nodes with the center of highways. If you unify them it reduces information and makes further editing more complicated.

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

    [Text](URL)
  • Image

    ![Alt text](URL)

Login to leave a comment