Thanks for the info.

Your reasoning makes sense, but I'm not sure it's the right way to go about things.

Apart from the 'mapping for the render' and 'one tag, one element' principles, it seems a lot harder to maintain and keep consistent. What makes Gruyere a town, as opposed to a suburb, or a hamlet? If we add a node for Gruyere, the town; why doesn't places like Hurstbridge get one?

I recently asked on the talk-au mailing list about the appropriate tagging, but it might be worth establishing whether suburbs should be 'double tagged' as boundaries and nodes?

Hi Mikideez,

Gruyere is already mapped as a suburb; what is the benefit of mapping it twice as a node?
---

Published using OSMCha: https://osmcha.org/changesets/113355648

Hello,

What is the benefit in splitting the lanes for a small, innocuous traffic island?

Surely a node traffic_calming=Island would be better?
---

Published using OSMCha: https://osmcha.org/changesets/113351171

Hey!

Hope you are enjoying your long weekend. :)

Your name popped up on OSMCha, and I had a quick look at this edit. Looks like you may have forgotten a lifecycle prefix on some of these former roads?

Also, you don't have to put 'Former' in the name, if you have the lifecycle prefix. osm.wiki/Names#Name_is_the_name_only

Regards
---

Published using OSMCha: https://osmcha.org/changesets/113210899

This edit looks really good! Good work. :)
---

Published using OSMCha: https://osmcha.org/changesets/113057679

No problems at all! Sorry it took so long to reply (inlaws, enough said!).

It can be deceptively tricky some times, but don't be afraid! Noone is perfect and iterative improvements are what make OSM great.

For this intersection, I'd suggest considering it as two junctions: The first is with Lyall/Wilson as a standard # shaped dual carriageway. In that junction you can add a turn restricton to prevent traffic south-west on lyall from using Wilson as a U-Turn Point.

Then, I would add a separate link way between the Lyall Carriageways for the u-turn. You can make it a one way road to stop the other direction using it as well.

Unfortunately there isn't an easy way to 'trial' an edit; there are more advanced tools for editing but I wouldn't recommend trying those unless you are prepared for a learning curve. Don't be afraid to make mistakes though; be bold, give it a go and we can have a look :)

Hi timetotom,

Thanks for your contributions so far! :)

In this change set you’ve introduced some ways that represent turn lanes (for example 996755528).

While I appreciate this is an effort to add richer derail, this is contrary to accepted editing standards and conventions.

Ways should only be split when there is physical separation between them (osm.wiki/Editing_Standards_and_Conventions#Divided%20highways ). Adding ways for turn lanes will confuse routing algorithms and make it impossible to use OSM data to get directions. Turn details, lane numbers and other features should instead be added to the main highway with Lanes:, Turn: and other tags.

I am aware there are a few other intersections in the immediate area that have been incorrectly modelled with the turn lane ways, so I can understand the confusion. However, the standard of keeping ways together until the carriageways split is overwhelmingly accepted across the community and the superfluous lanes will most likely be removed by subsequent editors.

I’m happy to discuss this in more detail; it took me a while to get the hang of intersection modelling but it’s very addictive when you get it right. :) although it’s not authoritative, Mapbox‘a guide really helped me out: https://labs.mapbox.com/mapping/mapping-for-navigation/modeling-intersections-for-map-navigation/

I also just noticed that a lot of the drive thrus and service lanes near the Monahans Rd intersection are layer=-1, which would imply that they are underground. The building/roofs above them should instead be layer=1 and the roads at ground level

Hey,

Just in regards to 112989176, there isn’t any physical separation between the turn lane and the main carriageway. Would you be able to adjust the turn off up to where the turn splits off?

Gday Bob. Loving your efforts mapping details within schools. :)

I understand what your intention is tagging these ways with access=customer; I'm wondering if access=destination may be more appropriate? I'm picturing extra-curricular activities/deliveries?
---

Published using OSMCha: https://osmcha.org/changesets/112978254

Hey Supt,

Firstly, sincere thanks for your reply. I appreciate the acknowledgement and effort to discuss these edits. I can see you are a prolific editor, and have contributed a very large amount of edits to the project for over a decade. It represents a considerable investment of your time and I do not in any way want to detract from that.

Rather than quote Wiki pages at you (I can see you've had those conversations before and have most likely already memorised the contents), I want to convey the significance of splitting ways, smoothing turn lanes, etc. Apologies for the verbosity; if I had more time, I'd have written a shorter comment.

Your reasoning for smoothing out roads to minimise 'clunkiness' is understandable, and logical. Maps are more than their functional value: they are representations of the world around us and help us understand the places we live. A lot of the micro-mapping on OSM seems to include adding individual trees, grassy areas and parks, because fundamentally people want their local area to look good on the map and consistent with their positive feelings to their local neighbourhood.

Fundamenally, maps are an abstract representation of a place. We use lines to represent roads, single colours to represent different foliage and a consistent blue colour for lakes and ponds, regardless of their actual variations. While it is certainly possible to create a map with those variations, instricacies and details, you would essentally be recreating a photo. No level of detail could ever make a map superior to a photo for a 1:1 representation of a place.

There is nothing wrong with smoothing a road to more accurately represent the geometry. I believe we share common ground on that regard. A road like way/574151674 could be made into a smoother bend for both accuracy and aesthetics. We can add nodes to the road to make it look smooth, but if we zoom in more, we can still see the lines between the nodes. No matter how much we smooth the road, we cannot get the mathematical precision that the road engineers on the ground were able to achieve. I mention this philosophical point encourage you to accept that the map cannot, and will not, ever be perfect enough. Perfection is not for mere mortals to achieve. :)

With that in mind, consider a slip lane off a wide carriageway; such as this lane I picked at way/157806869 at random. Human behaviour being what it is, some drivers will turn immediately into the lane as soon as it opens up. Others will wait until there is a wider opening before they merge. Others, (mainly BMWs in my experience) will slow down, stay in their lane before moving into the slip lane at the last moment. Buses might take a wider turning circle to turn into the lane, and motorcyclists might hug the left hand paint. How can we represent the paths all these drivers take with a single line? We cannot. Any line we draw will inevitably not reflect the behaviour of some number of drivers.

As long as we consider mapping roads as lines, and not areas, there is always going to be some level of awkward geometry at these points. And that's okay. We will never be able to be perfect, so we choose a method that represents the average of all changes, even if it might not be as smooth as real life.

Now, you might ask why, if perfection does not matter, that adding smooth turns is a problem. Surely they are no less imperfect than a "clunky" method.

Here we must acknowledge the way this data is stored and used. These roads are just a series of numbers in a dataset to a computer, even a very clever one. The computer cannot tell the difference between a smoothed turn into a slip lane and a fork in the road; a turn lane in an intersection from a separate road. For it, a line is a road, full stop. It may be possible to build a computer that can tell the difference, but OSM hasn't done it because it's really hard. Look at Google Maps, Apple Maps, Bing Maps. they all have the same "clunkiness" at the intersection I mentioned not because that is the most realistic representation of driver behaviour, but because it has proven to be the best way to represent and store road details.

It is the way that GPS's, navigation systems and routing software interpret the data. It is the way that data consumers expect the data to be structured. It is the way that academic researches build their analytic models to examine. It is the way that geospatial analysts across government and industry use road data in real-world implementations and planning.

That is why the overly smoothed slip lanes, separate ways for turn lanes and overlapping ways are discouraged, and why you are finding that your efforts are being reverted or "simplified" back into the clunky version.

There is still significant value in adding detail to enrich the map, but I implore you to consider the points I've raised above and reflect on the suitability of your intersection practices. I'd also encourage you, if you haven't already, to discuss this further on the talk-au mailing list. There is a wider community there that is full of people much more knowledgeable on this topic than me.

Dian.

Hi! Me again; I’m a bit disheartened to have not received any engagement here.

There are some changes here that are debatable in this change, but there are one or two changes that I strongly disagree with.

way/112825020 does not need to exist. There is no separate roadway here for the left and right turns. Putting two ways here is not correct practice and is not a correct representation of the intersection. It causes routing problems and is confusing for users.

This is the same for way/995500551. This junction is more complex, (made more complex by the unnecessary split for a very minor traffic island, but regardless) yet there is no need for two ways from that lane.

Please engage with me on this conversation; these changes are fundamentally incorrect and undermine the usefulness of OSM in every use case. Continued prolificacy in this area will require significant remediation for other editors.
---

Published using OSMCha: https://osmcha.org/changesets/112825020

Thanks friend!

Keep up the good work, I’ll see you around.

Hi k_au. Thanks for your contribution in the Cranbourne Area. :)

In regards to the change you've made to Avonbury Circuit, I'm not sure if splitting the ways into two one way sections is the best approach.

way/993599090 and 112641991both end up creating forks in the road whereas the street is a single carriageway for its length. I would suggest a single node of traffic_calming=chicane is a better and more accurate representation?
---

Published using OSMCha: https://osmcha.org/changesets/112641991

Hey Warin, et al.

Came across this conversation while looking at recent conversations.

The list of acceptable sources for data includes the Vicmap datasets; the websites of which then direct to mapshare as a way to ‘explore’ this data. Perhaps this is a confusion of terminology, more than it is an ineligible data source?

Hi Stevo,

Was checking out some updates randomly and I came across this edit. Quite a lot of the turn lanes seem to split from the main carriageway well before the points where the roadway split. way/976266396 is a good example.

As a result of this, routing software would have problems providing directions correctly: the turn announcement would be too early, and it loses the ability for drivers to perform a late merge (ie, I can still enter the turn lane well before where the split is.) The geometry of the turn off will cause issues as well: instead of announcing a left turn, it is likely that the turnoff will be interpreted as a "fork" in the road, giving unnecessary and confusing turn instructions to vehicles travelling straight.

Could I suggest that a) the turn lanes we represented as a separate way only when there is physical separation (see turn=*#Motorway_with_links_and_destinations) and that the turn:lanes keys are used instead?

Separately, I also see you split Fosters Road into a dual carriageway way/992580619. Is this really necessary? There is no physical separation for almost the entire stretch of the road, and the only obstruction are two small traffic islands. Would it not be easier, simpler and more accurate to leave as a single carriageway, and add a two traffic_calming island nodes where required?

Lastly, regarding T-intersections for dual Carriageways. MY interpretation of osm.wiki/Dual_carriageway#How_to_map is that when two dual carriageways meet in a T intersection, it is better to map as a box, rather than a < shape. (while not authoritative, mapbox has a good guide https://labs.mapbox.com/mapping/mapping-for-navigation/modeling-intersections-for-map-navigation/).

I realise this is a length comment! Happy to discuss further.

Hi Supt_of_Printing,

I can see that you've adjusted your style of modelling intersections based on my previous comments, and I am thankful for that.

I'm concerned though that you have converted High Street into a dual carriageway in a stretch where there is no physical separation. As far as I can see, there is no need for way/991058192 to exist. A really small traffic island can be modelled better as a node in my opinion, but even still at the very least the dual carriageway extends too far.

Also not sure if the way you've split the intersection at De Burgh is correct. It looks like it's split too early, which has then required the superfluous ways 991058192 and 991058192.

Also, I'm still concerned about the geometry of some of the turn lanes: node/991058192 is an example of where having the turn off so smooth would be interpreted as a fork in the road, rather than a left turn into a slip lane.

Happy to discuss

Thanks for the details Velloydy. I was curious because it seems like such a big area to be private!

These kind of private developments are always a bit odd in terms of tagging, but I'd suggest that access=private isn't the best description for this case.

Even though it is private property, if the streets are publicly accessible (ie, can I walk my dog or ride my bike through the area, even if I don't live there?) then a different tag might be better suited.

If, for example, there was a gate there with a keypad for residents to gain access, that would clearly be private; as a random person I can't go looking around!

(Also noting that Google products don't have the right license for us to use to make maps with, just in case you weren't aware :) )

Hi! Thanks for contributing. :)

It looks like there are already two areas here for the construction of the New Footscray Hospital.

way/818272392 and way/820385657

Would you have any objections if I merged the two?

Hey Velloydy! Thanks for your contribution.

I wanted to check with you the access for River Dr. I can see you’ve marked it as access=private. Is that because it is private property, or is it a gated community?
---

Published using OSMCha: https://osmcha.org/changesets/111750356