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.

did you confirm node/12793967751 via survey? Without a survey you can't really know if it's a ford or a bridge or a culvert.

I've repair it now.

Hi, we now have two objects for Dalrymple-Hay Nature Reserve, where we should only have one. It's preferable to retain the history osm.wiki/Good_practice#Keep_the_history where possible, so in this case I'd like to remove the duplicate you just added and repair the existing relation.

Thanks, I've re-added it as not:highway=path to prevent it being re-added by future mappers as such.

You can't really tell from the Mapillary or Bing Streetside image we can use. We can't use Google Street View for mapping due to licensing.

Thanks. You could consider adding sidewalk=no to say there is no footpath here.

In the case of https://osmlab.github.io/osm-deep-history/#/node/11568757353 the operator:wikidata value was correct, so in iD selecting "Tag not the same" is incorrect. You can either ignore the warning or opt to upgrade the tags to update the operator tag from "TfNSW" to "Transport for NSW".

Thanks for confirming, I've restored it and retagged as a roof, but left the netball pitch you've restored as I have no idea what's under the roof.

No worries, I've fixed that. iD was warning about outdated operator:type syntax.