cześć andy,

totally off-topic, but as i operate a legal-loophole open wlan accesspoint, may i suggest you use https:// links to pascal's site?

that's how i have it bookmarked, as well as a https-everywhere rule as too many internal links lead to sniffable URLen.

of course, verify these links can be followed without certificate errors. i've whitelisted pascal's site long ago.

thanks

hi baden,

thanks for the reminder. several unfortunate crashes took this issue from my screen, but not from my guilty conscience of unresolved osm issues. i'll see what i can do after two days of catching up on other osm ... issues. who would have thought such a free-time hobby would be so ... zeitraubend, sorry, can't think of a convenient equivalent to describe how much of my useless life has been lost to osm.

details to follow

i thought i addressed this in my response to an unfortunate racist/ausländerfeindlich comment in the us of a. every osm user should have the right to communicate in the way most comfortable to them. there are plenty of translation sites to introduce comical errors not present in the original language, and you are welcome to hovercraft full of eels.

hallo facebook,

this is weird. you have added the tag n=yes, akin to the pre-existing import=yes, in this changeset.

that i expect from an infrequent potlatch2 bug i am tracking now, but this was a josm edit, where i have seen `n' point to what i guess was meant as `note' elsewhere in a different facebook edit.

do you have any idea what `n' here was intended to expand to?

thanks

neither your changeset description, nor the source you have provided, are of any use.

osm is not a creative writing contest, but a serious mapping activity.

what is this changeset description supposed to mean?

and how am i to interpret the source you have provided?

given many of these 43 camp sites are scattered over the autobahn at exits, i think a massive retagging, or a revert, is in order. native speaker needed.

shalom,

maybe the mapper feels more confident in russian or hebrew, and like me, chooses the language best conveying her or his meaning.

machine translations (that i don't use at all) are good enough that one can have a good laugh at their flaws, when i know people laugh at me behind my back for my word choices in their native tongues when they're not laughing in me face.

dosvedanya

stupid question time, do you remember your intent behind the tagging of way/505121298 ?

aha! hello,

i see you also use potlatch, to explain how something like this has happened.

way/446168142/history has changed here from surface=asphalt, to v=asphalt, where i found it today.

i want to check these and similar changes are an error i now understand, and are not deliberate damage rather than removal. i would normally fix these quietly, but i have discovered several such corrections that have been DWG reverted.

gracias. viva la potlatch! (especially potlatch 1 i have been using for these repairs :-)

hello,

i see you used potlatch like me, so now i have an explanation why i see keys being changed, when updating other fields directly above.

but i wanted to verify this was not deliberate, as in this changeset, i see that way/561050955/history went from lanes=2 to s=2, where it remains today.

gracias

cześć, amazon (guessing)

i would go further and categorise two of the three service drives added here, near where i removed the co-located node, as service=parking_alley to further narrow them down like a private residential driveway.

no, parking_aisle, sorry, i really need sleep as i can't remember the simplest things anymore. see mapbox imagery for details. that would slightly change how the ways should be drawn in detail, but that may be nitpicking under strict definitions.

hej,

if this is amazon, please check your mapping here. i'm seeing a cluster of duplicate nodes in georgia that were not there 24 hours before the osmi cutoff shortly before 18h gmt yesterday (as of 2min ago)

more importantly, viewing this edit against archive clarity showed an arc north of this, and nowt on the ground.

i then switched backgrounds to something more recent and with mapbox i see a clearing but it's obviously for the leccy as i see no track. and indeed to the north in mapbox i still see a drive.

if you have continuous gps traces that show this, i could believe it, but if the signal got lost over this length i'd expect the device to be under heavy canopy for the duration.

and sorry if your plan was to use osmi to find these rather than the iD close_nodes warning i see above.

wow, now that i have examined things, it seems you have been very busy as a team.

it seems this TN12 highway was split at the edwards mentioned in the changeset description from an over 10km length, several days ago, creating a virginal section to the north.

i would advise to be careful with this, when relations are involved, as that is how one of uber or lyft came to my attention on the west coast months ago.

(and i need a kezboard, not a touchscreen, as i had to re-type that, grrr)

here you can only get to the north section of tn12 directly from way/712975140 . so i wonder, not understanding routing or mapping, if you would be directed to turn right, and after 0 metres, turn 180 degrees south at the co-located nodes on the north part.

it is an iD bug as far as i am concerned, and i think from the issue raised some months ago, it is known but unresolved.

hi,

if you can find a better imagery than maxar, use that for better looking results. here the archived clarity images from bing that are about a decade old, taken from aeroplane overflights, but have been better corrected to align the roads than any satellite imagery, recognised from being nowhere near as sharp.

i am guessing without checking that this is an amazon contribution, and i understand it is more important to you to get things approximately correctly on the map, rather than to create so-called ``beautiful'' curves that i would spend several times as long to create.

note the choice of imagery varies, and archived bing is a good rule-of-thumb for the continental us. i have found it helpful to use the floating window feature my potlatch2 editor offers me so i can use the latest, unclear, poorly-aligned imagery to immediately detect if something visible on crisp mapbox has since been rebuilt, maxar being a good candidate for that. i do not know if iD has that feature.

i should also give a heads-up that when you start mapping in canada, i have found the maxar imagery is much older where in some places, only bing shows thebuildings added.

my attention was also drawn to this changeset by detecting a duplicate node here, i will fix, and wondering who mapped things so far off from my background. :-)

and if you are not amazon, sorry

lucky for me, there were still older tiles at lower zooms showing the whole riverbanks, so i started looking in the wrong direction until i zoomed in further.

much nearer the lake i saw where it diverged from the woods cleanly enough and the single deleted item folllowing that course was clear, unlike where the rivers meet and there appear to be hundreds of deletions, none looking sensible.

wait, i thought i sent this off already.

it looks like a segment you want back was deleted in this changeset and can be seen at https://osmlab.github.io/osm-deep-history/#/way/434850562

it was obviously part of a relation, but i have not dug that far just yet, though you can see if it works as an outer by itself.

the scary tying is i had seen my username appear on one of the segment history to the south a week before you deleted it.

which is probably the last time i slept. feels that way.

i don't think this changeset deleted it. i'm totally unfamiliar with this area, and my attempt to undelete near the junction where now i can see what you are talking about reveals an unholy mess, so i'll either try up northwards, or review your other commented changesets...

are you asking for a revert, or for detective work, for what i see now as relation/6447166 shows a lot of inners that are now outside of the stub that remains as way/712561121 .

at the least you may want to add all the outer inners to your new relation if accurate as a lot are missing, and remove them from the old relation. your new relation at a quick glance only seems to have a handful.

moin moin advert amant,

i zoomed into https://nrenner.github.io/achavi/?changeset=72879760 and set the background to plain osm to be able to see anything, and where there were nodes they were not tagged as pylons previously.

it was also v1 of a tiger import typically intersecting with electro-auto-roads and frying-fish rivers, so from my past experience following tiger lines and adding pylons, i don't think you need to worry, but it would be nice to see extant ones mapped.