thanks, is a typo, fixed now

thanks, this one fixed as well

Hi Stephen, it looked complete, but there was a temporary fence blocking access around node/13325879916

feel free to change it to construction, i won't be back any time soon to check

Hi Warin, thanks your recent comments. All the multipolygon issues should be fixed now. And cheers for fixing the massive broken forest. I'll check back once the validator has updated

also as an FYI, I'm working on improvements to iD (https://github.com/ideditor/schema-builder/pull/174 ) so there'll be a warning in the edito rif type=boundary isn't closed, or isn't geometrically valid. hopefully that will prevent these kinds of issues in the future

hey phoebe, could you take a look at node/12600563378 please - the name=* and name:mi=* tags seem to contradict each other.

Is this a copy-paste error? or if not, should we add alt_name:mi=* to avoid confusion?

Hi Andy, these riverbanks/islands change after every flood, and I guess DOC doesn't update the legal boundaries when that happens, which is why we get such a mismatch.

I've merged these boundaries together now to keep this area more organized , so feel free to keep editing around here :)

Cheers,
Kyle

Hi, what are you trying to achieve with these edits?

if you ignore those validator warnings, it creates an enourmous mess that someone will probably revert.

we don't map each individual lane as a lane, the previous layout was already correct...

you changed the entire 600km² forest (relation/2891664 ) into scrub - is that intentional?

no, the railway community prefers to use duplicate tags for some reason.......... see https://taginfo.osm.org/tags/railway=waste_disposal#projects , some apps only support railway=waste_disposal and not amenity=waste_disposal

yeah, I now know how to do this properly, so hopefully you don't see many such mistakes from me. Apologies for this one.

I still think it's worthwhile improving iD's software, so that we don't inadvertently break things like this. I'll follow up in the issue tracker on GitHub

@Warin61 could you open an issue in https://github.com/openstretmap/iD please? If the editor doesn't tell people about this issue, the same problem will just continue to happen

agreed, but in this case we might need both tags? since many of these track crossings are controlled by pedestrian traffic-lights

p.s. there's also railway=tram_crossing which might be even more fitting

thanks for these edits, this is the new trail that's opening next week right?

*sos

heya, nice work adding all these details ! do you have any thoughts on the tagging scheme itself? (osm.wiki/New_Zealand/Railways)

I asked for feedback in a bunch of OSM forums, and got heaps of comments from Germans, Australians, etc. but not a single response from any other kiwis

The current tags are not set in stone - the only app that supports them right now is https://openrailwaymap.app/#view=15.21/-36.847515/174.780519&style=signals

so if you've got ideas or thoughts, please let me know - I'm certainly not an expert. and I've already found one flaw: you can't have a low-speed and restricted-speed light on the same node, which I thought was impossible, but there's 1 example of this in Penrose, Auckland. maybe others too

sounds good, yeah I think this was discussed on the discord too and the consensus was ref=*. fixed now

sorry but this isn't correct, the physical bridge pillars were built on different dates many months ago.

the date that the cycleway opened is different, and recorded by the start_date=* on the way/1221288557

Thanks for your edits! out of curiousity, do you use any software that depends on these MOE:* tags?

At some point, they should be mass-replaced with the standard OSM tags (e.g. changing all MOE:years=* to grades=* ).

But that will break any software using these tags, so I'm trying to figure out who (if anyone) makes use of this data

hey mateusz, yes it's a typo, fixed now

thanks! sorry i missed that very last sentance somehow. done now: changeset/176176211