Hi, just want to understand your reasoning for removing the kerbs.

What does "not specific in tagging" mean?

And I guess with the new construction in the area, the kerbs are changing a lot, or where is there any need to "maintain" mapped kerbs at all?

(This is not meant as a criticism for removing them, I just want to understand why you removed them as I've been mapping a lot of kerbs in North Lakes.)

I agree that it would be possible to just tag something (and it would actually be pretty straight forward to do so, take the definition of relation:restriction for a relation:permission with a role of u_turn_permitted), but the lack of support for this in iDs turn restriction editor makes creating them quite fiddly, and without support for it in routers, it's unfortunately pretty pointless.

Here are the "by law" rules for u-turns in queensland in the absence of signs, which (mostly) shouldn't be mapped as turn restrictions:

https://mypolice.qld.gov.au/sunshinecoast/2020/06/01/u-turns-how-well-do-you-know-the-rules/

I'm having a hard time trying to make sense of this changeset. It seems to be primarily a huge amount of unnecessary and/or faulty turn restrictions? (there are countless u-turn restrictions that fall under "Don't map turn restrictions that are the default for a given jurisdiction and are not signed. It is much better to ensure that routing engines embody the regional rule rather than mapping every occurrence as a turn restriction."

(Yes, the situation is complicated in queensland in regards to signaled intersections, because the law here is "u-turns are not permitted unless signed", but OSM doesn't seem to have a standardized way to record turn *permissions* as opposed to turn *restrictions*)

And I also noticed unnecessary restrictions in places where there are missing one-way tags, where the correct solution is adding the oneway tags instead of adding 6 turn restrictions.

Would you please elucidate your thought processes behind this changeset? Thanks!

Thanks for noticing that something was wrong with
way/589935481/

But it shouldn't have been deleted, instead the missing relation that it should be part of should have been added.

(I've undeleted the way and added the missing relation).

Ah, thanks for that information. It does indeed look slightly (a few months to half a year I would guess) newer than ESRI in some places. (Though it seems to be much lower resolution.)

Oh, also, for this local area, you may want to change your imagery to "Esri World Imagery (Clarity) Beta", which has generally newer, higher resolution, and especially important, much better aligned images than Bing.

Thanks for your contributions to OSM.

You may want to use more descriptive names for your changesets that actually say what changes you made. If you find that you can't describe the changes you made in a single statement, you may want to consider splitting your work into individual change sets that concentrate on a specific change to allow you to label them all appropriately. Thanks!

Thanks for the quick fix! It's unfortunate that the definitions of the plain lanes=x tag (counts full sized vehicle lanes) and :lanes suffix tags (can include cycleways and various other things which are not counted by the lanes=x tag) is inconsistent with each other.

Same as the other. One of the :lanes is a cycleway which should not be counted as part of the simple lanes=x tag

Thanks for destroying the previously correct lanes tagging. One of the "lanes" represented in the :lanes tags is a cycleway, which should not be counted in the simple "lanes" count, which only counts fullsized vehicle lanes.

"Still it is suggested to let the residential landuse end at the actual border and not extend it to the centre of the road for various reasons, e.g. to simplify later refinements (highway landuse), not to locate things on the public land (road) in adjacent landuses and to avoid inexperienced mappers accidentally connecting roads to landuses rather than other roads."

It's one thing to be lazy when you add new landuse yourself. It's another thing when you purposefully go out of your way to change the work other mappers have already been doing to do this properly.

"Still it is suggested to let the residential landuse end at the actual border and not extend it to the centre of the road for various reasons, e.g. to simplify later refinements (highway landuse), not to locate things on the public land (road) in adjacent landuses and to avoid inexperienced mappers accidentally connecting roads to landuses rather than other roads."

It's one thing to be lazy when you add new landuse yourself. It's another thing when you purposefully go out of your way to change the work other mappers have already been doing to do this properly.

This is by far not the only changeset where surface areas have been wrongly merged to the road center-line. I fear this is going to take a massive reverting of 100+ changesets to clean up and fix.

I would like to kindly ask you to stop vandalizing existing landuse and similar area boundaries and not extend them to the road center-line. These areas stop at the kerb line and do not include the area that belongs to the road surface.

Please revert this and the other 100 or so changesets where you've been vandalizing existing mapping efforts, otherwise I think this will need to be referred to the DWG.

TIA.

Specifically, bike lanes are not counted in the lanes tag, which counts full sized vehicle lanes.

But they are shown as separate lanes in the different :lanes suffix tags, which are not limited to full sized vehicle lanes.

Don't know how many other ways you've vandalized like this, but the data is incorrect now.

The lanes tag counts only full sized lanes, of which there are 3 here.

The :lanes suffix tags includes all lanes, including bicycle ways, which is why there are 4 lanes described in the :lanes suffix tags, but the lanes tag was saying 3

when I looked for a source for that data I found osm.wiki/Data.australia.gov.au/Queensland and used that.

If that information is incorrect it should be fixed.

Is the PSMA import imminent? This should only have been done right before the import, or even as part of the import change set, because without this area (which btw was traced pretty exactly from cadastral data) Nominatim is going to wrongly associated a lot of addresses in North Lakes with Deception Bay, Rothwell, Dakabin, and Mango Hill (based on the distance from the address to the current place nodes, picking the closest one)...

Oh, also, I would recommend using ESRI Word Imagery instead of Bing for the area around North Lakes as it has higher resolution, is more current and sharper, and after crosschecking with various other sources, seems to be much better aligned then Bing in this area.