Hi Patio, first and foremost thanks for finding and the attempt to fix this--it was evidently my inadvertent mistake (likely just hitting the wrong macro hotkey for my set of custom presets) when adding a kerb ramp (sidewalk connector way) upgrading this crossing to PWG Silver Tier geometry and tagging last night.

I do want to point out that the correct--and simplest--solution here is simply copy/pasting the correct tags from the adjacent sidewalk way to the existing mistagged way (or manually removing the accidental, if technically correct tactile_paving=no and adding highway=footway, footway=sidewalk and the rest). It seems for some reason this changeset instead created an entire duplicate way tagged (only) highway=footway footway=sidewalk, while also leaving the spurious way tagged only tactile_paving=no in place. It would also have been helpful to pick up the various other tags of the rest of the adjacent sidewalk for consistency's sake, particularly the access tagging meaning that this only fixed this for pedestrian routing, not bicycles.

It seems to me that iD should have warned you about this, especially given it is newbie oriented and that his mistake is both not uncommonly made by such as well as relatively easy to detect being a pretty basic geometry issue whereas the original error was much higher-order--I'm a little surprised it evidently didn't. (Though I guess not _too_ surprised given how limited iD's validator is compared to JOSM's, which did of course detect it albeit not the original issue given it is much harder to catch--my custom suite of tagging rules _should_ have caught it, but I didn't have them all enabled at the time).

In any case, as I noticed it flagged via OSMI in JOSM, I've already fixed the issues from this changeset as well as properly fixed the original mistake in changeset/182184557:

changeset/182184557

Cheers, and happy mapping!

Fair enough. Personally, unlike any human user where I'd assume good faith (or even a business owner trying to add their own business to the map), I treat these throwaway accounts of a known SEO spam ring with every bit as much respect as they treat both the OSM community and their customers ;)

Of course!

BTW, thank *you* so much for all your recent improvements to HDYC--it's gotten even more useful as a tool to analyze and celebrate both my own mapping and that of others!

Thanks @pitscheplatsch !

Thanks!

Hi,

If you're going to add businesses to OSM for your clients, you have an obligation (to both your client and to us) to at least make every reasonable effort to use correct tags and values. A number of the tags added here are used incorrectly (addr:street=*, opening_hours=*), which both pollutes the map with junk data and means they will not be intelligible to data consumers reading the map, defeating the purpose of your efforts here.

It's really not _that_ hard to use iD's beginner-friendly presets to fill in this information correctly, or spend a few minutes reading the wiki on how to format your tags properly. After all, you are being _paid_ to do this properly for your client.

Furthermore, upon investigation checking the latest ESRI imagery from less than a year before this changeset, it appears there is nothing anywhere near this point that could plausibly match the POI; the only two bits of human geographic within 1000 ft (300 m) is a church and a cemetery, neither of which I would assume host an insurance business.

Therefore, given the lack of any evidence for this place existing on the ground anywhere near where it is mapped, as well as the bad tagging and SEO spam purpose of the changeset, I will have to go ahead and remove it.

Hi,

If you're going to add businesses to OSM for your clients, you have an obligation (to both your client and to us) to at least make every reasonable effort to use correct tags and values. Essentially every tag added here is used incorrectly to the point of being nonsensical, which both pollutes the map with junk data and means they will not be intelligible to data consumers reading the map, defeating the purpose of your efforts here.

It's really not _that_ hard to use iD's beginner-friendly presets to fill in this information correctly, or spend a few minutes reading the wiki on how to format your tags properly. After all, you are being _paid_ to do this properly for your client.

Fortunately for you, other volunteer mappers already fixed most of this for you in changeset/181169404 changeset/181169404 , and I fixed the remaining issue in changeset/182055783 changeset/182055783 To be honest, given the complete lack of good faith effort in this changeset if that hadn't been the case I would have reverted it out of hand (and other mappers would be justified doing the same). Consider yourself warned.

Thanks.

Hi,

If you're going to add businesses to OSM for your clients, you have an obligation (to both your client and to us) to at least make every reasonable effort to use correct tags and values. addr:street=* is incorrectly abbreviated and does not match the name=* of the street it is right next to, and the city and address is incorrectly included in the name=* tag (if present, they belong in branch=*). More importantly, the POI you added is missing any top-level tags describing what the business is, meaning it will be useless to most users of the data and defeating the purpose of your efforts here.

It's really not _that_ hard to use iD's beginner-friendly presets to fill in this information correctly, or spend a few minutes reading the wiki on how to format your tags properly. After all, you are being _paid_ to do this properly for your client.

However, since most of the tags were correct, I went ahead and added top-level tags for you as well as fixed the name=* and addr:street=* in changeset/182055731 changeset/182055731

Thanks.

Hi,

If you're going to add businesses to OSM for your clients, you have an obligation (to both your client and to us) to at least make every reasonable effort to tag things correctly. This POI is missing any tags that describe what it actually is, which means it will not be picked up by most data consumers reading the map, defeating the purpose of your efforts here.

It's really not _that_ hard to use iD's beginner-friendly presets to fill in this information correctly, or spend a couple minutes reading the wiki on what tags to use. After all, you are being _paid_ to do this properly for your client.

However, since the tags you have added are correct and not spammy, I've gone ahead and added the missing tags for you in changeset/182055619 changeset/182055619

Thanks.

In addition, the entire commercial building was given the name and address of one single individual unit within it, which is of course not correct. I've fixed this as well as other related issues in 182055477 changeset changeset/182055477

Hi,

If you're going to add businesses to OSM for your clients, you have an obligation (to both your client and to us) to at least make every reasonable effort to use correct tags and values. Most of the tags added here are used incorrectly and many are completely nonsensical (addr:street=*, completely missing addr:housenumber=* , healthcare:speciality=*, Hours=* [sic], Payment=* [sic], phone=*) , which both pollutes the map with junk data and means they will not be intelligible to data consumers reading the map, defeating the purpose of your efforts here.

It's really not _that_ hard to use iD's beginner-friendly presets to fill in this information correctly, or spend a few minutes reading the wiki on how to format your tags properly. After all, you are being _paid_ to do this properly for your client.

Fortunately for you, other mappers did your work for you for free, fixing most of the tags, and I've fixed the rest for you in changeset/182055354 changeset/182055354

Thanks.

Especially when mapping for a client, it is your responsibility as a paid professional to use OSM tags correctly. In particular, addr:street=* incorrectly includes abbreviations and doesn't match other addresses in the area, as iD would have told you it's payment:american_express=* and payment:cheque=* not payment:amex=* and payment:checks=*,, service:vehicle:auto_repairs=* is not a known tag, it's website=* not Website=* (OSM tags are always lowercase), and phone=* is missing the country code.

Most of this was fixed for you by another mapper in changeset/13546019384 node/13546019384 with the remaining bit (addr:street)=* fixed by me in changeset/182055184 changeset/182055184

(Also, it's payment:american_express=yes not payment:amex=yes , which you would have seen if you'd looked at what iD suggests)

Especially when mapping for a client, it is your responsibility as a paid professional to use OSM tags correctly. In particular, opening_hours=* doesn't even attempt to resemble the correct syntax, addr:street=* incorrectly includes abbreviations and doesn't match the actual road it's right next to, and unless used as part of the common name of the location (on signage, etc), legal signifies like "LLC" do not belong as part of the name=*.

Fixed in changeset/182055039

changeset/182055039

Hi,

If you're going to add businesses to OSM for your clients, you have an obligation (to both your client and to us) to at least make every reasonable effort to use correct tags and values. Most of the tags added here are used incorrectly (addr:city=*, addr:street=*, cuisine=*, opening_hours=*, payment=*, phone=*, website=*) , many of them being essentially nonsense, which both pollutes the map with junk data and means they will not be intelligible to data consumers reading the map, defeating the purpose of your efforts here.

It's really not _that_ hard to use iD's beginner-friendly presets to fill in this information correctly, or spend a few minutes reading the wiki on how to format your tags properly. After all, you are being _paid_ to do this properly for your client. As it stands, given the mostly nonsensical tagging and violation of OSM policies on spam, it is your responsibility to fix this.

Thanks.

(It's a SEO spam account, just FYI)

NB, it's a SEO spammer

Hey, thanks for updating this! NB, a bot will come around and fix it, but just FYI standard format for US phone numbers on OSM is +1-NNN-NNN-NNNN (+1 NNN-NNN-NNNN is also widely used, and +1 NNN NNN NNNN sees some use, both of which are acceptable alternatives)
---

Published using OSMCha: https://osmcha.org/changesets/181961856

> I still flip between VBMP and other map layers as there's more information to be gained by using a variety of maps due to different exposure, foliage, and timeline. That is why you continue to see Bing imagery as a source in this changeset.

Yup, that's great and totally what you should be doing. The feedback I was referring to above was our reminders to make sure you set the correct offset for VBMP imagery before using it (Bing has close to zero offset, within the margin of error of GPS tracks, at least at high zoom levels), as was the issue here (given the building outlines are not aligned with correctly offset VBMP (or Bing), and instead perfectly match raw, un-offset VBMP.

> I was unaware that you can apply offset to maps to assist alignment. I'm more than happy to do this for future edits.

Yup, I'm a JOSM user but it also works with iD/Rapid, under the Imagery Offset dropdown at the bottom of the Background panel on the right (where you select the imagery)--you can just paste the values I've suggested above there. However, unlike JOSM I'm not sure iD/Rapid actually save your offset setting between settings (like so many other display settings, very annoyingly, one of the many reasons you might consider moving to JOSM at some point in your mapping journey).

Hi Mitch, just a reminder--per what Frank Peng and I both mentioned to you on several of your previous changesets, please make sure you set the correct offset your aerial imagery before mapping with it, that will avoid everything you map being offset and requiring correction later, which for spending a few seconds now avoids requiring way more time and effort to fix it later.

VBMP is much closer than Bing to orthorectified in this area, but is consistently offset by over a meter to the north and west; by my reckoning via Bing and GPS tracks an offset of roughly -0.95; 1.10 will correct that (slightly more or less depending on the exact location, but this offset is roughly correct for this location to perhaps 10-20 cm precision).

Unfortunately I can see from your changeset here that you mapped directly from raw VBMP only with no offset applied. Again, before you continue mapping, *please take care to apply the proper offset to your VBMP imagery* to avoid everything you map being misaligned with the real world and the work of other local mappers.

Thanks, and happy mapping!