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

Furthermore https://palmbeachferries.com.au/ seems to indicate that "Palm Beach Ferries" should be the network and the operator should be FantaSea Cruising"

In my view the name should be the actual route name, not some concoction based on a preset format of MODE: STOP_FROM => STOP_TO. If data consumers wan't to show the route name in that format they can built it from the data. the name=* should match the actual name used for the route "on the ground".

https://palmbeachferries.com.au/timetables/ shows the route names in use.

Do we really need to specify the platform names in to/from. Simply Sydney -> Broken Hill seems much simpler and better for people using the data.

I don't think the name should be updated from GTFS data alone, especially to a non-name name, it seems like the prior name "Broken Hill Xplorer" is correct.

can you provide any further information on why this is access=no? What kind of signage is present on the ground?

Although looking at this change are you sure it's correct?

In general I think the preference is to have the network set at a lower level than simply "Transport for NSW". The regional trains are a different network to the metro trains, than to the suburban trans and intercity trains, each should be on their respective network.

"Transport for NSW" seems to be the more common value https://taginfo.openstreetmap.org/tags/operator=Transport%20for%20New%20South%20Wales vs https://taginfo.openstreetmap.org/tags/operator=Transport%20for%20NSW

It appears in a bunch of presets so ideally we'd use the same value for network here.