Absolutely, if possible. I only map this way as a last resort.

Here's one I remember doing a while back: osm.org/way/249606377

It's signed 798-812, right under the Colonel's nose. It's 798-812 on the website ( even right in the url: https://locations.kfc.com/ny/brooklyn/798-812-4th-avenue ). There's no reason to think the restrooms are 798 4th Ave and the drive-thru window is 812 4th Ave. By all available evidence, the real-world address of this place is 798-812. So that's what I tagged, and added the address interpolation way to boot. Frankly it's hideous, but I still think it's less bad than any currently-available alternatives.

"-" really is a damned boondoggle. I really wish Queens hadn't adopted it as separator punctuation in their addresses, and I really wish other New Yorkers wouldn't use it to sign ranges. But they did, and they do.

I've struggled a lot with how to deal with this. When a poi really does appear to be using the whole range as their housenumber (2752-2758 in this example) my instinct is to angrily tag what I see.

The other obvious tactic is just to tag it with the lowest housenumber in the range. This looks better from a data hygiene point of view, and avoids any Queens-style confusion. But it conveys less information, and it doesn't follow OSM's "truth-on-the-ground" best practice.

Nonetheless, putting the whole range in addr:housenumber is annoying enough that I'd much rather just use a single number, if I can justify it somehow. The good news is, I think I can justify it here -- seems this place has a website https://www.atlanticcarsale.com and the housenumber listed there is simply 2752. So, making believe that the website is equivalent to on-the-ground signage, I've changed this car dealer to `housenumber=2752`.

I could talk about this problem all day, and probably should at some point.

If you haven't read it yet, here's NYC's summary of the address formats in use & how the city's own geocoding software handles them: https://nycplanning.github.io/Geosupport-UPG/chapters/chapterV/section02/#house-number-format-standards

And here's a proposal for a tag that might be of use to us, if it were ever adopted by geocoders: osm.wiki/Proposal:Addr:interval

Aha, thanks. I've removed all the Giovanni tagging from osm.org/node/2550089888 and left it as a disused restaurant.

The website says "diagonally across the street" so I'm guessing it means at osm.org/way/249624759 which has been vacant as long as I can remember. I left a note there so we can keep an eye on it.

Haven't heard back, so I've removed this parking node and left a note requesting survey.

Re osm.org/node/10835701238, this parking area had been mapped as osm.org/way/854537978 but as far as I know it's been closed for years. Do you have information that's it's been reopened?

Well I've removed this name from the parking lot since I can't find any reason for it;, let me know if that's a problem.

Hi there, I'm wondering about the name "Grand Central Parkway" for the parking lot at osm.org/way/25346338 -- is this perhaps a mistake?

Just noticed this little under-prioritized segment of Union Square East, secondary when the rest is primary: osm.org/way/420598402

I was inclined to just delete it and extend osm.org/way/923090985 south to meet osm.org/way/923091012. My impression here is that this would be fine as far as the bicycle tagging goes -- the stretch currently covered by osm.org/way/420598402 has two-way bike lane paint and the southern end can be approached (dismounted) via the crosswalk. Just wanted to make sure I'm not missing anything.

Thanks, J

Yeah thanks, they changed names & kept the old phone number but I should've yoinked the website tag!

August 2022 was almost a year ago -- an eternity for NYC ;) Here's a pic from a couple of days ago: https://postimg.cc/N9kQYCwv

I surveyed this spot last month and removed these crossings, see osm.org/note/3749278 ... but I probably should've left the crossing ways in place, marked them disused, and added a fixme for future survey -- because if they're still visible on aerial imagery there's always a chance that someone will map them without actually surveying or checking with locals first. So that's what I've done this time (changeset 138563718).

In locations where there are active mappers and you're unable to survey personally, consider contacting the local community or leaving a note or fixme, and please check for notes & fixmes that others have left.

Also please be aware that, although useful as a reference, the Cyclomedia imagery hosted at geocoder.nyc is not licensed as a data source for OSM. Only imagery that's been explicitly released with an OBdL-compatible license can be used for mapping. This is why it's important to be explicit about your sources for each changeset.

Thanks, Jmapb

Hello! I'm wondering what the source is for the name and boundaries of the residential land use "Old Church Bell" (osm.org/way/108220707) which you added 12 years ago.

Thank you, J

Has this crossing been restored? osm.org/way/1075789633

Howdy Iván!

Please don't use the "fixme" tag to describe why you've made an edit to the map. It's great to know why, but that information goes in the changeset comment.

A "fixme" tag should be used when there's a known issue with a particular feature's data that needs to be addressed by OSM mappers in the future. See osm.wiki/Key:fixme for more info.

Thanks, J

Gotcha -- yeah, better to put it just on the path, not directly touching Lawrenceville. As it is now, it looks like traffic driving along Lawrenceville has to pass through that gate as well.

Ok I *think* I managed to unsplit those roads without undoing any of the other work. The bus routes still have problems, but they did before too, so no big change there.

...It's from a different changeset ( osm.org/changeset/136673392 ) but I was also wondering about this gate sitting in the middle of Lawrenceville Street: osm.org/node/10934511170

Yeah I was gonna suggest that.... let me take a stab ;)

Ok, I guess the big question is whether Ulster Ave should be split into a dual carriageway... Generally we only do this is there's a physical divider of some kind, not just road paint. (See osm.wiki/Dual_carriageway .)

If it *is* valid to map as dual carriageway (I was on Ulster Ave on Wednesday & I'm appalled that I can't remember!) then that has a lot of impact on what turn restrictions are necessary where. Eg, this only_right_turn that I added at the exit from Kings Mall:
osm.org/relation/14697083 ... it was useful when Ulster Ave was two-way, but exiting onto a one-way road it's redundant.

osm.org/relation/14697154 is even worse... it made sense when I added it, but now it applies to traffic traveling south in the northbound lanes, so it's completely meaningless.

There are also implications to the bus route relations... eg see how this bus route now jumps between the northbound and southbound lanes: osm.org/relation/12678504#map=18/41.96173/-73.99022

Hi bedouin_88, welcome back to OSM!

Fellow Kingston mapper here... l saw some of the restrictions you added on Ulster Ave and I'm a little confused. Can you explain what you're working on here?

Thanks, jmapb

True, true... but there are plenty of street and place names whose current spellings diverge from their etymologies.

The only other source for the possessive form is TIGER (notoriously bad in this regard.) Meanwhile, the street signs say MARKS, the imported addresses say Marks, the PAD file says MARKS, GOAT says MARKS, ZOLA says MARKS, DOB says MARKS, and the bus and bike maps say MARKS. I'm pretty sure that's the correct form.

I would have put Saint Mark's Place in as alt_name, but these ways are already tagged alt_name=East 8th Street... maybe Saint Mark's Place would actually be a more useful value for alt_name though.

Hi there... it's obvious that Moe's Pastrami & Burger (osm.org/node/10247751973) is not Moe's Southwest Grill, so I fear that you may be "fixing issues" based on the map editor warnings rather than your own knowledge.

Please only add things to the map that you personally know to be true, and only remove or change things that you personally know to be inaccurate.

Thanks, jmapb

(I've already fixed Moe's in changeset 136350431.)