BoJo said that? i didn't know, i just knew the expression pre-dates current politics by several decades, at least.

osm, where you learn something new every day. whether it's useful is another topic entirely.

no worries -- had your edit gone as planned, there would have been no problems with eight CT locations in a single changeset.

you did well with the changeset comment so it was immediately obvious something had gone pear-shaped with such a large bbox.

since there were relatively few items in this broadly-spanning changeset, it was trivial to open them all for the non-graphical manual review, which admittedly was not to verify what was done, although i have done so for similar wide-area changesets elsewhere.

one reason for people complaining is the relatively naïve history function. a better history function would only notify mappers interested in CT or the canadian glastonbury, but not detroit, milwaukee, or colorado.

the achavi tool works great for smaller, localised changesets. if there were no memory issues, such a large area would result in the affected areas being displayed as tiny dots, requiring extensive zooming to get details. then again, as i note, despite the vast area covered, your changeset description and the small number of objects makes a manual review tolerable for this edit.

to be more specific, now that i've looked at this small number of changes, while seven of them are clearly in connecticut as your changeset description claims, you may wish to have a look at relation/7825323 , a glastonbury located near edmonton in alberta, canada.

i have an uneasy feeling you probably intended this edit elsewhere. like in the area of node/158813072 , for which i am failing to find an obvious administrative boundary relation.

try to take a look at https://nrenner.github.io/achavi/?changeset=76060793

you have made eight changes, in areas that span a wide area. if the above link worked, i would point to you the standalone items too far from any others which should have been saved to a separate changeset so as not to create such a large area as you see to the right, spanning several provinces and completely engulfing four or five states.

by saving each independent changeset by itself, you will have up to eight much smaller areas that do not span across hundreds of kilometres where there were no changes, yet people monitoring areas within are notified of this edit even when totally unaffected.

hello, google employee, and welcome to openstreetmamps!

you, google employee, are very welcome to contribute to openstreetmamps, but i find this a bit puzzling, as you wrote in a personal message dated 19 October 2019 at 19:40, and i quote:
> Have fun getting your account banned.
> P.S. I quit OSM and work at google maps thanks to you.

well, google maps employee, i am happy to welcome you back to the fold, even if it means i can no longer trust you to keep your word.

there is nothing wrong with being a google maps employee like you are, yet still contributing to openstreetmamps. in fact, we encourage it. we just ask that as a google maps employee with access to sources that are the intellectual property or the possession or the sweat of the brow of google maps, that you do not allow those sources to influence your contributions to openstreetmamps.

that is, as you as a google maps employee have access to an irrefutable source that the street on which an elementary school is sited has been renamed to Penis Street in honour of Dick Penis or Penis Johnson or someone, i don't remember. after you have updated google maps, your employer, please resist the urge to transfer this vital knowledge to openstreetmamps unless the limited array of sources legally allowed for use in openstreetmamps can also confirm the same.

i trust that as a google employee who turned your back on openstreetmamps, your change of heart will be reflected by the utmost quality of your contributions, which should reflect the quality of work that google maps has hired you to perform.

i look forward to seeing further classy contributions from you, google maps employee, to openstreetmamps, and please understand that despite you turning your back to us upon being the lucky recipient of quick gainful employment, we at openstreetmamps do not hold grudges, and offer the warmest of welcomes to all mappers, no matter their other life interests.

this bubbling glass of yellow ambrosia is for you, cheers

and no aerial imagery shows this as any sort of highway. also, this is obviously not an urban area so there are no osm municipal parks here. and it is very odd to rename a lake after yourself following earlier edit wars.

of the last three of the 12 edits so far, only node/2024623195 , the address node for Weinmeisterhaus, corresponds to a publicly visible node of Freifunk Berlin at https://www.freifunk-karte.de/ (among others).

the tagging of
internet_access wlan
internet_access:fee no
seems not optimised for this use case, where freifunk requires no registration or permission, and using no encryption, is available to all without any formalities whatsoever, something not conveyed by identical tagging being used for encrypted networks that require one to request access as a café or hotel customer, for example.

can i assume FreeWifiBerlin is mapping open (freifunk and similar) access points which may not be visible on the particular community's map, or are the other two nodes in the last two of 12 changesets networks that do not charge for use but are not open by default, or maybe are open but in private hands rather than a freifunk participant?

so what's wrong about open WLAN networks? i'm operating one right now with a foreign client connected to it.

please to be enlightening me.

i agree the shop value should show the what; the how or why is second-hand to that.

does this quote from the wiki help?

For a shop=* that sells a specific type of good (e.g. shop=clothes), use second_hand=* with value:
* yes if it sells new and second-hand items
* only if it sells only second-hand items

Example: A used car dealer could be tagged
shop=car
second_hand=only

georg, amazon did not create a new way from nothing. this new way exists as a result of splitting an existing way, and the correct thing for any editor to do, be it iD, osm, potlatch, or whatever, is to preserve the existing tagging for the entire previous length before splitting.

such splits are necessary for adding turn restrictions, or, say, for adding a lanes value that varies across the previous extent.

if the editor utility fails to preserve existing tagging, that is a bug, as i experienced many times analysing edits made with iD by lyft/uber (i no longer remember) where it seemed that one out of every five edits would result in one of the route relations getting dropped for no clear reason.

here is a case of GIGO; apparently in the past some mappers felt it was okay to draw long segments and add multiple values, each valid over at least one part of the segment. my potlatch editor threw up a warning about this. i've also seen multiple semicolon-separated names where today we would map two roads.

i don't know what is best here, do a mechanical edit to delete all such multiple value cases, or leave the bad data and hope data consumers choke on the logic and don't present it to the end-user, or prefix it with a top-level unparseable like bogus: or bad: so that nobody save humans or qa-tools that look for that prefix see it, but the original data does not get lost...

there are so many missing speed limits that i fear simply deleting them here is not going to result in someone immediately mapping them in detail, even if one sets a pop-up note or fixme.

just my view...

looks good. i was worried that the newly-added overlapping road was lacking connectivity to two sets of pedestrian crossings, but josm worked with the old segment. there were no other conflicts as far as differences between the overlapping ways here, as there were in the previous overlap where i needed to merge all junctions just to be sure.

good work, thanks.

as is `Stable (horses)' in way/734645073

you may not delete the building based on google maps or imagery. you may not use google maps either as a source for osm, nor as a reference to update the osm data as you have done. to do so goes against the google terms of service, as well as osm policy.

as the building you deleted seems to be visible in all legally available imageries osm has permission to use for the map, unless you can justify the deletion by some other source which osm may use, i am afraid i will have no choice but to ask the dwg to purge the reference to google maps in order to prevent future legal liability to osm.

you have also deleted some 20 ways listed below, only to re-draw most with minor variations.

this loses the history of mashin's contributions making it appear there was nothing there, and that goes very much against the osm policy to preserve the history and respect other users' edits.

if you don't feel you can pull existing nodes to a new position and add new intermediate nodes to smooth things out, the way i updated part of a crude imported outline around lake of the ozarks or somewhere, then at least use the josm plugin to merge the previous geometry history with the new from-scratch one.

hallo georg,

it looks as if you should have restored v3 of the node, as it presently has the name of some business, plus additional info that should not be part of the name.

i'll probably see if i can pull up v3 for you to get the name (printer? odd) correct again.

ciao

> location from another users note

be careful about this. while onosm.org was naïvely conceived as a way for small businesses to put themselves on the map by proxy, recently in the english-speaking countries i monitor, it's been discovered by lazy or vandalistic seo companies, so that it often feels like half the onosm.org notes are placed on the city or town nodes, and a diminishing number are from real businesses themselves.

take a look at note/1966310 added more recently at this same spot.

> Do you suggest we add and move the poi location?

your call. i nuke any notes like the above that are obviously from uncaring seo companies that want to do the least work possible to get their sucker^H^H^H^H^H^Hclients onto the map somewhere, anywhere. i don't feel it is an appropriate use of mapper resources to research these misplaced notes and do unpaid work for these paid seo companies putting the often dubious businesses onto the map as if osm is some business directory with neat popups exploited by the ^Business\ Name advert-copy gang where less than 5% of notes worldwide are anywhere near the actual location, a large proportion being on an entirely wrong continent.

like i say, i leave it to you or any other mapper whether to re-activate any of the notes i've marked as wrong, visible at https://resultmaps.neis-one.org/osm-notes-country-feed?c=United%20States&a=closed and add the data in some correct location.

be advised in the above link i was mostly offline, so the cases of `city/town node spam' are concentrated at the start now.

australia was particularly hit by this bad geolocation a month or two ago.

agreed.

node/3651038416/history was obviously tagged correctly by a local mapper, and it's not surprising to find crystal glass shops throughout bohemia as well as the rest of ex-czechoslovakia that are no more than (souvenir) shops.

one would think this user would have ceased these types of edits following so much criticism of earlier similar blind mechanical edits as well as numerous repeated reverts (where i seemed to get solely blamed for inappropriate activity).

sorry, you can't add an area (recreation ground) tagging to an item that is a way in way/543977804/history

isn't this a rather unlikely place for a lawyer?

it looks to me that you've memorialised some misplaced onosm.org spam co-located on the city node before i could get around to nuking it. there is no building here.

and how is it that washington dc got included into a `vias Popayán' colombia changeset? something to do with RapiD maybe?