When Mapping Polygons surrounded by streets should they share nodes or be traced separately? I don't know what the best practice is for parks or other polygons that are surrounded by streets, should it be traced around on it's own or should it be traced on top of the street nodes. This question has been bugging me for some time. asked 05 Nov '12, 18:33 redsteakraw aseerel4c26 ♦ |
It is the case for most mapping techniques that it is all up to the mapper. If you are mapping in an area with a number of contributions by another user, try and follow their standards for mapping. I like to follow the general rule that if I am creating an area that includes the grass buffer along the road , I go up to the road (ex: landuse=residential, landuse=commercial, leisure=park, other community-type things). If it does not include the grass buffer, I show it going up to its actual location (ex: landuse=farm, landuse=forest, natural=wetland, and other agricultural or natural areas). The only potential problem created by this for the mapper would be that you would then have to make sure that you reconnect nodes if you disconnect them. While I found this annoying at first, I quickly developed a habit of making sure that the nodes were connected again. answered 23 Feb '14, 05:02 ItalianMustache |
I find it much easier to maintain shared node boundaries, at least most of the time. Adjusting to ever improving air photo data, for example, is a lot nicer with shared nodes. Shared nodes also tend to make for neater cleaner rendered maps, especially on specialty products (for example a bike map where bike route streets are rendered extra fat). Node sharing is not right in every area. But I think it's right in a lot of rural areas, and I think it reaches it's limits once you start to micro-map street furniture, traffic lights, trash cans, fences, or details down to that level. The shared nodes are a simplified model of the world, which is fine for a huge fraction of the planet surface. answered 22 Feb '14, 00:15 Bryce C Nesbitt I think your first part contradicts your last part. Aerial imagery is improving, other positioning methods are also improving, so it gets likely that your last part becomes reality. If it does and nodes are shared they first have to be unshared/duplicated/triplicated and assigned to the right object. Yes, if aerial imagery would only be improving in offset but not in resolution (and no alignment with e.g. gps traces is done) then I understand your first part.
(22 Feb '14, 01:00)
aseerel4c26 ♦
2
@Bryce C Nesbitt: There's a problem with your approach of starting out with a simple method that stops being practical when we add more detail: Those who want to add more detail to a previously roughly mapped area have to work harder than if the areas were not glued onto the ways. This is one of the reasons why this topic is sometimes so hotly debated, and why some people switch into the "separation" camp once they start to upgrade areas to more detailled mapping.
(22 Feb '14, 14:44)
Tordanik
1
You answer is a bit off-topic, as the OP was asking about sharing nodes with a street, not a boundary. It's an important distinction, because a boundary is zero-width and doesn't cause logical fallacies when sharing nodes with an area. There are some physical objects, such as fences, which everybody considers to be zero-width (I have yet to see a fecns mapped as an area). They can happily share nodes too (a fence can even logically define the edge of a forest, for example). But it's too much of a stretch to consider roads to be zero-width.
(22 Feb '14, 21:36)
Vincent de P... ♦
@Vincent, there's no true logical fallacy mapping an area next to a road. Take a forest road. The "forest" in fact runs to the "edge of the road". If the road is widened the "forest" still runs to the "edge of the road". The moment the road is modeled as an area, the forest polygons again should be connected to the edge of the area. Drawing a forest area with a road cutout is doing half the job: the road at that point should be an area. @Tordanik the people micro-mapping are typically well prepared for the editing operations needed to unglue the ways. And they only have to do it once.
(23 Feb '14, 01:28)
Bryce C Nesbitt
We draw sidewalks and paths connecting to road centerlines, and that's not strictly true either. As less than 1% of the planet surface is micro-mapped, concern over the effect on micro-mapping seems overstated, especially given the skill level of most micro-mappers.
(23 Feb '14, 01:35)
Bryce C Nesbitt
Call it a "geometrical error" if "logical fallacy" is off the mark. But if stopping short of mapping the road area is doing half the job (I tend to agree, even though road areas are still very rarely mapped), then mapping the park at the centerline of the road is doing a quarter of the job. A valid approximation, but not one that wistands scrutiny using high-res imagery. The "edge of the road" only makes sense if the road has an edge; which a 1D zero-width object cannot have (an edge is the limit between inside and outside, but a line has no inside).
(23 Feb '14, 19:48)
Vincent de P... ♦
showing 5 of 6
show 1 more comments
|
I'm a new mapper, but I would still strongly advise against sharing nodes between ways and areas because editing becomes much more difficult later for whomever. If some person later disconnects nodes on a way and one of those nodes is helping define an area, they may not realize that the area's node is also disconnected (it certainly is) and may well leave the area disconnected even if they re-connect the way since that may involve moving or recreating the node in question. I can tell you it's happened to me and I just count myself lucky that I happened to think about it later on and discovered what I had done and fixed it. It's more work making things parallel, but your polygons will be far less prone to accidental editing. answered 25 Jul '13, 05:22 Evan Edwards |
I have tried both. Shared can look neater but it is a real pain to edit later.But,If you use Potlatch2, there is a parallel line tool in the tool box which you could find usefull. I haven't used it in this way yet but i will give it a go. The paralell tool as lots of less obvious uses, I have used it to make several identical buildings for example. answered 18 Dec '12, 12:07 andy mackey 1
It's also really handy if you're mapping areas like industrial sites with lots of storage tanks--you can roughly trace one, use the circle tool to make it a proper circle, then use the parallel tool to create more circles, even of different sizes.
(19 Dec '12, 14:47)
neuhausr
|
Short answer: do not share nodes between a way and an area. Long answer: when representing a road (physical 2D object) using a way (logical 1D object), we've made a simplification. We know the road has a width in real life, but it doesn't have one in the db. On the other hand, when representing a park using a closed way, we haven't simplified anything. It is an exact (if approximate) representation. Linear objects and planar ones should be thought of as belonging to "separate universes". Sharing nodes between them leads to logical fallacies. For example, it'd mean that the park really does extend up to the middle of the road. Sharing nodes is tempting because it is less work at first (especially if you want to connect the park to the road network, for pedestrian routing purposes), But it is incorrect (as explained above), and it can make later editing more cumbersome. answered 05 Nov '12, 19:24 Vincent de P... ♦ 1
It looks nicer to have two areas share points, but it's almost never worth it imho..
(05 Nov '12, 19:48)
emj
Now I am really confused. Take a look at: I have always considered it to be that areas and ways could share the same boundaries, but it seems that I am wrong! Please clarify.
(18 Dec '12, 06:56)
dcp
2
It is common for highways and areas to share nodes in OSM (as it is common to make them NOT share nodes), but it shouldn't be done because it is less detailed and creates some problems (the areas get bigger than they are, objects on the street seem to belong to the area, it is harder to edit). If you want adjacent areas to share nodes with the street you should map the street as an area (additionally to the center line).
(04 Jul '13, 11:22)
dieterdreist
1
You can share nodes, and nothing stops you from sharing nodes. It's a valid, but not universally applicable or liked, mapping technique.
(22 Feb '14, 00:18)
Bryce C Nesbitt
It is not "incorrect". It is simplified like the 1D road, as you said. And they are many places where the detached polygon is also approximate (especially when data source - the aerial imagery - is not so good)
(25 Feb '14, 09:55)
Pieren
|
This depends on personal preference. You will find people within OSM that will tell you either method is the only right one. They will have a load of arguments for their point of view too. There is no clear majority for either method. My personal POV is that when mapping in an area where there is already a lot of detailed data (e.g. in a well mapped city centre), then you should do the same. In other words trace separately. If you're mapping in the middle of nowhere and want to map the forest on one side of the road and the farmland on the other side of the road, then I would share the nodes. answered 05 Nov '12, 19:09 cartinus 1
Ah yes, I should have mentioned that there isn't a full concensus on this subject, instead of simply stating my POV. But hey, my POV is by definition the best one, right ? :p Now that we have a "no" and a "it depends" answer, maybe we need to add a "yes" answer. So that I can counter the arguments in the comments :p
(05 Nov '12, 19:32)
Vincent de P... ♦
1
I agree, as I see you are interpreting sharing nodes of lines and polygons as an intermediate solution for less detailed areas (i.e. you do it like this because despite being less precise it is faster and you accept this compromise in order to get more mapping done). The conclusion on the other hand is that not sharing nodes is more precise and should be preferred when you have time.
(04 Jul '13, 11:25)
dieterdreist
|
Nearly the same question: is-it-okay-if-landuse-borders-share-nodes-with-streets-rivers.