Hello. :)

Thanks for your contribution.

After a small discussion on the talk-au mailing list (https://lists.openstreetmap.org/pipermail/talk-au/2021-September/015042.html), it was generally agreed that tagging a suburb as a 'town' isn't correct.

I'm currently in the process of reverting a whole bunch of these town tags back to suburbs. You can see what it looks like in the south east where all the suburbs have been configured as nodes. I can change this node to a suburb and attach it as a label to the relation if that's easier for you? :)

I'd encourage you to join the mailing list (if you haven't already) as its a great place to talk and discuss changes with fellow mappers.
---

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

Hey TuanIfan,

I know this edit was ages ago, but I'm doing some updates and noticed a lot of the Chinese names you've added to suburbs.

Are these names transliterations, or does the Chinese community in Melbourne use these names in place of the English names?

Dian

Yes, thanks. :)
changeset/114019540

Fixed.

Hey Supt.

Firstly, I apologise for making you feel like you are being watched. It is not at all personal: like many editors, I use OSMCha to view recent change sets. Your name keeps popping up on the list because you’re so incredibly active, and because your edits quite often fail the OSMCha validation checks which highlight in red. These validation checks are automated (they look for crossing ways, really tight angles, etc), and while they don’t indicate that you made an error it causes your edits to stand out. I’d recommend OSMCha, generally, for editing and reviewing; I find it useful to see where I’ve made an error!

I missed that the previous edit was undoing an earlier change of yours; and I totally understand where you are coming from. I genuinely don’t know what the best approach is for these, which is why I’ve asked the question. (If the ways split, then it’s unclear whether a u-turn restriction is required as well)

I’d really encourage you to participate on the mailing list (https://lists.openstreetmap.org/pipermail/talk-au/2021-November/015306.html) I’m only one person, and I’m definitely not infallible. You do a lot of really good work, and your viewpoints are just as worthy of consideration and discussion.

Dian

Hey Supt,

In this edit you've seemed to reverted most of the changes made by another editor in changeset https://osmcha.org/changesets/113587813.

While there isn't a strong consensus, the wiki does seem to suggest that "roundabout flares" should me mapped as a single node, rather than splitting the way: junction=roundabout#Roundabout_Flares.

I've raised this on the talk-au mailing list now for their POV, but I'd suggest checking out the history of an element. :)
---

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

Hey Supt,

In this edit you've seemed to reverted most of the changes made by another editor in changeset https://osmcha.org/changesets/113587813.

While there isn't a strong consensus, the wiki does seem to suggest that "roundabout flares" should me mapped as a single node, rather than splitting the way: junction=roundabout#Roundabout_Flares.

I've raised this on the talk-au mailing list now for their POV, but I'd suggest checking out the history of an element. :)
---

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

Hi!

Why? These seem like transliterated names, which aren’t suitable for inclusion? osm.wiki/Names#Avoid_transliteration

Yes, I see that as well. Some of the other suburbs have names in other languages on just the node, or area; others have mismatching tags.

I’m happy if it’s an established standard, just would prefer it to be consistent with every suburb (in Melbourne at least).

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