Per highway=motorway_junction highway=motorway_junction is really the tag for a motorway exit, it's the node along the motorway where you can take an exit, so it's no suitable for an interchange.

The way at way/1292847049/history is still probably the best way to mark the interchange, you could do a relation which includes all the road segments, but this area way also does the job in my opinion.

So I think it's best that all the interchange tags are moved to the way and we drop highway=motorway_junction, and not on this lone node in the middle. The way does a better job at showing the extent of the interchange and all the roads which form it, if it's just tagged as a node we don't have an idea of scale of the whole interchange site.

We don't really have a suitable tag for an interchange currently.

If there's nothing left on the ground should it even be mapped here at all? There's OpenHistoricalMap for historical features. If it is kept in OSM then abandoned means there's still some evidence on the ground, according to osm.wiki/Lifecycle_prefix#Stages_of_decay it seems it might be razed?

way/1383500133 should be demanding_mountain_hiking not alpine? It's not typically alpine here.

Not sure what this has to do with Google Maps, this is OpenStreetMap. But thanks for confirming the dedicated bicycle lights in that case we can use designated.

Seems reasonable to me.

do the signals have a bicycle traffic light? eg like https://www.nsw.gov.au/driving-boating-and-transport/roads-safety-and-rules/bicycle-safety-and-rules/riding-bikes-near-pedestrians

If they do it should be bicycle=designated + foot=designated.

We're using "designated" if there is signage or markings for exclicty use by that mode rather than "yes" which just means is legally able to use it, but no markings or signage indicating it's specifically for that mode.

Thanks. You should explicitly set oneway=yes on these.

No reply, I've reverted this in changeset/165534070

I think comparing based on proximity is the best way to link them to your data. Sometimes we do include external references but I'm not sure that's best here.

Thanks for replying.

Do they really need suburb tagged?

It's already discouraged to add addr:city to most addresses since suburb boundaries are already mapped. In this case the level crossing is on the border of two Suburbs relation/3173338 and relation/12079778 but our suburb boundaries are not that accurate and features near the border are more ambiguous.

Regarding the source, I just think that it's misleading to add the source tag as you have to existing level crossings, as the source for those was likely not TfNSW's Open Data but organic OSM mappers from local knowledge, ground surveys, street level or aerial imagery. So best to just set your source on the changeset level not the each level crossing feature.

Good to know you've updated your dataset, apart from applying names were there any other discrepancies you've found?

Would it be worth me updated the Map Roulette challenge at https://maproulette.org/browse/challenges/49134 with the new data? Otherwise what process are you following, are you just going through each of them manually and comparing?

ps JOSM has tools to make it easy to generate the parking space geometries from the outline + entering row/column counts. Much easier than manually drawing these out.

That's it though, if anything they act like a unit not addr:housenumber.

How you have it currently means the house at 30 Wicks Road node/6395430523 is the same address as way/332096380 which you've also tagged as addr:housenumber=30 which is then inside the campus which has addr:street=Wicks Road giving the hospital building 30 Wicks Road, which is wrong.

addr:unit is usually for a townhouse or apartment within an address, not usually for building numbers.

I'd still tag these as ref=* since they are reference numbers for the buildings within the campus.

Then separately to ref=* I'd also consider if there's a way to incorporate them into addr:*=* tags, likely just using addr:full for now.

Furthermore an import must go through the proper import process.

I've previously proposed and worked through an import of this data at osm.wiki/Import/Catalogue/AU_NSW_TfNSW_Railway_Level_Crossings you can see the kinds of documentation and community consultation you should do.

If they aren't address numbers don't use addr:housenumber. If they are building numbers/codes use ref=*. If they are unit numbers you could use addr:unit but I think in this case they are probably just building numbers/codes which should be ref.

That said, if they are used for addressing then they should also be included in the addr:*=* tags addr:*=* but I'm not sure of where. You could also use addr:full for the full postal address.

Depends where you look for parking_space, for example way/1058112357

Regarding the source, it's best used per tag eg source:name=* or better yet on the changeset. Since it's not quite correct to say the source was from the open data portal since it was added independently beforehand.

What is the location value for?

The location key as documented at location=* doesn't match how you're using it, and I don't think it's right to use it as you are.

Can you hold off these edits until we resolve this?

These likely should be under ref=* ref=* per osm.wiki/Names#Name_is_the_name_only

amenity=parking_space should be used for each individual parking space not a group of them. You can always still use amenity=parking for the whole parking area.

For the addr:housenumber's if you know the addr:street that would be helpful too.

The public_transport=station is already mapped in the member way way/1261363035 so best to leave this one as the stop area. If you think that's wrong please discuss first, as no justification for the change was given in your changeset comment.

As such I've reverted this changeset in changeset/165569170

In Australia according to https://taginfo.geofabrik.de/australia-oceania:australia/tags/boundary=protected_area we have 8,586 as relations and 3,802 as ways so both are used and valid.

Until OSM can better support retaining an object history as it changes between a node/way/relation I'd prefer to leave it unless it needs to be changed. Sometimes it's unavoidable so we have to accept the history becomes more fragmented.

It does show in iD though, if you select the way then select the relation that the way is part of you end up with osm.org/edit?changeset=165531563#map=17/-33.737030/151.157836 which is the relation selected.

I'm not saying we can't change it to a way, but let's discuss and consult other mappers first.