I've restored the prior route names based on community feedback at https://community.openstreetmap.org/t/public-transport-route-names/131624

I've restored the prior names based on community feedback at https://community.openstreetmap.org/t/public-transport-route-names/131624

I've restored the prior name based on this being the better route name over the artificial route name from PTv2 per community discussion at https://community.openstreetmap.org/t/public-transport-route-names/131624

I've restored the proper name "Dubbo XPT" based on this being the better route name over the artificial route name from PTv2 per community discussion at https://community.openstreetmap.org/t/public-transport-route-names/131624

I suspect the lanes:conditional should also be increased to 3 as likely it only changes by one lane during the AM lane shift. I'm not sure though.

if there's no arrows on the road or other road signs then we shouldn't be setting turn:lanes per turn=* it should only be used where there are road markings or sign markings indicating the lane guidance.

way/1396730552 turn lanes are not modelled like that, we only draw a separate way where there is physical separation, if there's just paint on the ground it's best to use the turn:lanes tag turn=*#Indicated_turns_by_lane to specify the turn lanes.

The existing way at way/40427397 already allows for routing from Spencer Street turning right into Gatton Showgrounds.

way/1396730553

I'm not sure about that one the routing will already let you turn there like this osm.org/directions?engine=graphhopper_car&route=-27.558516%2C152.278678%3B-27.558694%2C152.278799

usually we wouldn't model the intersection like that unless there is a large traffic island in the middle of the intersection.

The ways which join the road to the parking lots (eg. way/1396730532) should be "Driveway" (highway=service + service=driveway) not "Unclassified" (highway=unclassified). As a rule of thumb if you drive up and over the footpath it's a driveway. For example this is unclassified way/151689579

https://community.openstreetmap.org/t/public-transport-route-names/131624

if you had any thoughts on the matter if you could contribute to the thread please.

hi could you please reply to my earlier changeset comments about changing the route names? I might ask for wider community feedback, if you could hold off further changes until we get community feedback?

Thanks for confirming.

Are there freshly painted turn arrows on the ground? Imagery isn't showing any turn arrows painted. Or is there other signage indicating the restrictions?

turn:lanes is only used where there are markings on the ground or other signage implying it. And then it's only used for the section of the way that it applies to.

I've made some tweaks, does it still look ok?

I think on the basis that we mark the additional lane from when it starts, even if it's still to narrow to use at that point, it's okay to say this has 4 lanes total (2 for right turn) even though it only becomes wide enough for two further along).

Thanks. That's fine, just you had a typo in "slight_right" which I've fixed.

thanks!

but these two restrictions from/to the same way aren't needed (if they were we'd need them on every single road at an intersection).

relation/19267503
relation/19267500

most routers will apply sensible defaults and not request to do a uturn from/to itself via a single node.

where we do need those no u-turns are at traffic lights where the from/to are different ways (eg on a dual carriageway) since some routers will otherwise ask you to u-turn at traffic lights where you can't.

It's probably the iD editors fault those as it shows these same to/from restrictions as being allowed by default but they aren't.

Thanks, I was aware where it came from just strongly disagree with it being applied here, especially when it replaces an "on the ground" or "known as" name that was already mapped.

But good to see there has been progressing in removing this from the PTv2 standard.

> StreetComplete asked me which floor this shop was on, however coming back to it this info appears to be already tagged? I'm not familiar enough with indoor tags to know what's going on here.

We have two tags for floor level, level=* and level:ref=*

level always starts with 0 at the lowest ground level, and is always numeric, -1, 0, 1, ...

level:ref specifies how the level is referenced on signage, lift buttons etc. eg. B1, LG, G, 1, 2, ...

I find level:ref easier to survey and more useful to map as someone looking up what level something is on wants it to match what the signage says and the lift buttons say.

However level is also important for maps to make indoor maps because it gives a consistent ordering, otherwise (especially globally) we can't know the order from level:ref alone.

StreetComplete asks for and tags level and ignores level:ref which has been discussed at https://github.com/streetcomplete/StreetComplete/issues/3529 and https://github.com/streetcomplete/StreetComplete/issues/1487

Because level always starts with 0 at the lowest ground level, and some buildings use levels like LG, G, 1 you can end up with a situation where you have

level=0, level:ref=LG,
level=1, level:ref=G,
level=2, level:ref=1

And since when surveying a shop it's hard to know which level:ref number corresponds to the lowest ground level it's hard to survey level correctly.

similar comments about the route name

the previous bus route name seems to match whats "on the ground" better than the "MODE REF: FROM => TO" concoction