Sorry for the delay, just back from a little Long Path hike! (Luckily dodged the rain!)

Improving the way alignment is always welcome, of course. I was hiking with old OpenMapChest data on my Garmin and comparing it against current OSM data on my phone, so it was easy to appreciate your improvements.

Repairing a broken relation is also great! Please note thought that when you're changing a relation, it's very helpful to your fellow mappers to describe it explicitly in your changeset comment. As you've seen, it's common for relations to be modified unintentionally, breaking routes. Good changeset comments help us quickly sort through the intentional versus unintentional changes.

Completely reorganizing a large route relation is a more complex task, and we other Long Path mappers will appreciate some discussion beforehand. This isn't a rule, but it's well-established good etiquette. It helps others know that you're a cooperative mapper whose work deserves respect, not a vandal or edit warrior.

So... ignoring the irrelevant bits from the screenshotted slack discussions, the gist is this: The LP was changed to a superrelation because of software limitations. The idea was proposed to change it back to a normal route relation because those previous limitations were no longer an issue. There was discussion, there were no substantive objections, and the change was made and clearly documented in the changeset comment. For edits of this scope, this is a good model to follow.

Btw it's also confusing to do this using the changeset comment "started fixing more of the trails" -- that sounds like fixing map errors, but in fact you made a change from one valid relation style to another. See by contrast changeset/164512582 where the changeset comment explicitly describes the change to a single relation.

The consensus during last year's discussion was that since the various editors no longer have trouble with LP-sized route relations, using a single relation is preferred. Simpler is better, I guess.

As I said, I don't think having a superrelation of smaller routes that correspond with the Trail Conference sections is necessarily a bad idea. But given that the previous discussion landed on using a single relation, it would be helpful to discuss again before making these changes. If you're reluctant to join Slack then maybe start a topic at https://community.openstreetmap.org/c/communities/us/78

That's the second link I posted above, https://jmapb.github.io/matthewfecia/osmus.slack.com_archives_CJ4QKU40H_p1743775453702849.png

Indeed, I had forgotten about last year's conversation until quincylvania reminded me.

Slack's a useful tool for collaboration but I understand the reluctance to move conversations off of OSM's own ecosystem. I've screenshotted today's conversation (https://jmapb.github.io/matthewfecia/osmus.slack.com_archives_CJ4QKU40H_p1789676544582039.png) and last year's discussion that quincylvania linked to (https://jmapb.github.io/matthewfecia/osmus.slack.com_archives_CJ4QKU40H_p1743775453702849.png).

You'll see reading through here that the idea of "easy to troubleshoot" goes both ways. Using a superrelation based on NYNJTC's numbered sections isn't a crazy idea, but the consensus last we discussed was that this tends to make things harder to maintain, not easier.

Hi matthewfecica -- it seems like you're working on converting the Long Path into a superrelation of section route relations. There's a history here, and we'd like to come to some consensus as a NY/NJ mapping community before making this change. Is it possible you can join the discussion on the OSM-US slack instance? https://osmus.slack.com/archives/CJ4QKU40H/p1789676544582039

Thanks, jmapb

Came across this because JOSM's giving me a "Non-Way in multipolygon" error for Long Island relation/3955977 -- how's the experiment going? ;)

Hello fellow mapper!

Regarding footway=crossing ways 909331146, 909331156, 908944880, 908941864, 908940988 -- indeed it's been my understanding that a crossing:markings= tag means that crossing:marked= is unnecessary. Not a fan of redundant tagging in general, both for brevity's sake and to avoid data conflicts when tag values get out of sync. crossing:markings= is a well-conceived tag and popular enough at this point that any current software that cares about crossings should know about it. Maybe the documentation currently recommends otherwise? Feel free to add tags as you see fit. I don't edit-war on the map or on the wiki.

Regarding footway=crossing ways 1268825926 and 1268825927, mea culpa, looks like I've been using =uncontrolled wrong -- at least since the documentation page was edited on 2022-09-26 to claim that crossing markings are required for an "uncontrolled" crossing. News to me, but this has stayed in the wiki for 4 years. So even though it sounds illogical I'm not inclined to dispute it. I've removed =uncontrolled from these 2 ways.

Happy mapping, J

On second thought tagging them with an ID (ref:nycgreenthumb or something like that) would be more useful. Maybe the "gardensid" code from https://data.cityofnewyork.us/dataset/GreenThumb-Garden-Info/p78i-pat6/about_data

These signs indicate membership in the GreenThumb program, not that the gardens are actually city-operated properties. They do resemble the signs the Parks Dept uses for its own properties so it's bound to cause some confusion.

Being in the GreenThumb network does not indicate city ownership or operation. For example, the Suffolk Street Garden (way/207573814) is correctly tagged with operator=New York Restoration Project, but it's also a GreenThumb garden.

New York Restoration Project operates several gardens around the city, but most are run by local neighborhood gardening clubs. I can't promise there are *zero* city-operated community gardens (haven't surveyed them all!) but it shouldn't be presumed from signs featuring the Parks Dept logo.

If we want a tag that indicates membership in the GreenThumb program, I guess I'd suggest network=GreenThumb? (Or =NYC Parks GreenThumb to be a little more specific?)

Hi, what's the source for these operator tags? I'm particularly concerned with the community gardens, which are generally operated by local gardening clubs-- I don't know of any that are operated by the city.

Partially reverted in changeset/183746600 -- this changeset added invalid construction based on outdated imagery. In particular, way/1389210257 was added where Bing aerial shows construction beginning for a new bridge over the Esopus. The bridge was finished and mapped years ago, but it was incorrectly realigned in changeset/165022889 shortly before this changeset, which obviously led to some confusion here.

When mapping without local knowledge, please pay attention to how the date of the aerial imagery compares to the date of recent edits. Bing is pretty old around here. Feel free to leave a map note or contact a local mapper in cases of ambiguity.

Thanks, jmapb

Reverted in changeset/183746600 -- this changeset introduced incorrect road geometry based on outdated imagery. In particular, the bridge way/964074932 was moved to align with imagery of a previous, now-demolished bridge.

When mapping without local knowledge, please pay attention to how the date of the aerial imagery compares to the date of recent edits. Bing aerial is pretty old around here. Feel free to leave a map note or contact a local mapper in cases of ambiguity.

Thanks, jmapb

(see comments at changeset/138391273 and changeset/182755922)

(discussion continued at changeset/182755922)

(My changes were undone in way/1515002168, discussion here is continued from changeset/138391273)

Compare man_made=dyke to this picture from page 32 of the linked pdf:
https://jmapb.github.io/kguenther24/kguenther24-underground-flood-wall.jpg
It's pretty clear that the underground wall that the pdf depicts isn't a dyke. I'm not into edit warring, but if a dyke is mapped where no dyke is visible, mappers will be correct to remove it.

Maybe changing the tag would help, as well as tagging layer=-1 or location=underground. Regardless of the tagging choices, though, I think this approximate underground wall fails OSM's basic verifiability criteria, since a mapper on the ground can't confirm or improve it. (The inclusion of a check_date is especially odd -- nothing was checked!) I consider it to be part of the park's foundations, not a separate feature.

Finally, I'm really not sure these various flood control measures really merit a relation at all. IMO East Side Coastal Resiliency is a government initiative, not a geographic feature. But I left relation/16079502 alone, just deleted these two members.

Sometimes *is* helpful to map currently nonexistent features, if their geometry is actually known. In these cases it's best to use a lifecycle prefix (osm.wiki/Lifecycle_prefix) to ensure the map renderers and other data consumers won't see these features as current real data. Relying on tags like proposed= and start_date= isn't advisable, because you can't assume that data consumers will check for those.

Hi, I've removed the dykes way/1188974503 and way/1188974504 -- based on survey and imagery, these ways were running right through active parkland. Perhaps the plans changed, if so, this is a good example of why mapping things before they exist can be problematic.