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.

I'm not sure it's best to cut out the atrium like this as a building inner. It's tricky because it is open air on the NE end, but completely covered by a clear roof and still contains escalators and ground, level 1, level 2 walkways around the outer ring of the atrium and overall I'd consider it still "inside" and part of the building.

I think we either

1. map the N/S buildings separately as building=retail then use building=roof for the atrium, or
2. map the whole thing as one building=retail (without an inner), then use building:part's within it to model the 3D void of the atrium.

I think (2) is probably best and models what's on the ground best.

We should probably also move the shop=mall attributes to another way especially since some of the shops are within way/550340851 but still part of the mall.

reverted in changeset/167763531

please only use permissible sources for mapping

Hi Google Maps Street View is not a usable source for deriving information for OpenStreetMap. See osm.wiki/Google

You can use other street level imagery providers built into editors like Mapillary, Bing Street Side and others.

As such I'll revert this road as your only listed source is not compatible.

See osm.wiki/Relation:route_master the route_master relation should have the route relations as members not the first bus stop.

The network should probably match the network of the routes

hi what's your reason for adding these addr:postcode and addr:country nodes around the place? There are a bit meaningless without any other address information and can be derived from existing boundaries.