83 changesets created by sebastic have been discussed with 111 replies of this contributor
Changeset # Tmstmp UTC Contributor Comment
162283764
by sebastic
@ 2025-02-08 15:21
12025-02-15 18:23Famlam
♦305
Hi Sebastic, I get a lot of warnings from JOSM about duplicated nodes that very nicely follow the outline of the city. Possibly something went wrong here?
22025-02-15 18:37sebastic Probably the boundary=place relations using their own way members instead of reusing the ones from the administrative boundary.
151071564
by sebastic
@ 2024-05-08 19:03
12024-08-19 09:24eggie
♦40,705
Hoi Sebastic,

Denk werk aan de winkel.
https://www.openstreetmap.org/changeset/155446573#map=13/53.18953/5.48372

MVG
eggie
22024-08-19 13:20eggie
♦40,705
Jeroen Hoek heeft het al teruggedraaid.
Groet..
eggie
67018832
by sebastic
@ 2019-02-08 09:12
12024-02-02 15:08ligfietser
♦122
Bas, de wijkgrenzen van Amersfoort zijn in 2021 gewijzigd, bv de wijk Valleipoort bestaat niet meer, houdt jij dat nog bij? https://amersfoortincijfers.nl/jive?workspace_guid=f54da2a7-61ac-4e15-b038-629c05b5da3c
22024-02-02 15:49sebastic Ik onderhou alleen de woonplaatsgrenzen en de gemeente/provincie grenzen die dezelfde boundary ways gebruiken.
32024-02-02 16:07ligfietser
♦122
ok, dan zoek ik verder
100905652
by sebastic
@ 2021-03-12 11:41
12022-08-21 10:59ChehrehBargi
♦418
باسلام
ضمن خسته نباشید
جایگاه سوختی در اردبیل به سمت تبریز ثبت نموده‌اید که به صورت نقطه هست و شکل صحیح آنرا به صورت مولتی پلیگون ثبت میکنم.
با تشکر از زحمات شما
22022-11-19 07:50ChehrehBargi
♦418
Hello
dear @ sebastic
I edited this park by reading the wiki about the park and the polygon, as well as by asking old and experienced users, and by checking the parks of European and American countries. Your records about the green space are good, but there are some flaws. The registration that I ...
32023-05-22 13:10ChehrehBargi
♦418
hello sebastic
There is a gas station in Ardabil that I had registered as a polygon and you have changed it to a point. Multi-Polygon registration includes more details.
42023-05-22 13:23sebastic The polygon was broken two years ago (the geometry was not a valid polygon).

No need to contact me about these changes, just update the data to reflect the current on the ground truth.

The areas project is no longer active, not is the website for it. For some background information, see:

ht...
52023-06-19 03:54ChehrehBargi
♦418
The reason for recording notes for such revisions is to avoid repeating them in the future. And a little explanation for the reason for the complication change for the one who recorded the complication for the first time.
62023-06-19 04:13ChehrehBargi
♦418
I read the project that you started then. It was a big job. But in order to avoid those problems, users can be introduced to a resource that will teach polygon drawing in all conditions according to Wiki rules without ambiguity and in simple and complete language. In this case, we have millions of e...
47356122
by sebastic
@ 2017-04-01 13:57
12023-03-30 15:08zluuzki
♦224
Very old, I know, but:
You somehow left https://www.openstreetmap.org/way/33006092/history without tags. Guess that wasen't intended like that.
22023-03-30 15:23sebastic The tags moved the relation the way was an outer member of: https://www.openstreetmap.org/relation/110752

That's how proper multipolyons as structured, see: https://wiki.openstreetmap.org/wiki/Relation:multipolygon
100979525
by sebastic
@ 2021-03-14 08:11
12022-12-06 10:59JOTI
♦2
The border between Kuwait and Iraq is completely wrong in the norden part. Check Google maps, they have the border right. Have spoken whit Kuwait National Guard, and they confirmed that the boarder is wrong.
22022-12-06 11:14JOTI
♦2
Bing map is wrong :-)
32022-12-06 11:15sebastic Google maps is not a source that can be used in OpenStreetMap.

This changeset just fixed broken polygons, the accuracy of geometries is out of scope.
42022-12-06 11:25JOTI
♦2
Okej, what is the best way forward to correct the Kuwait/Irak border so that it is correct? Source kan be Bing Imagery you see the border clerly on that.
52022-12-06 11:34sebastic Ideally get authoritative data from a national geo agency under a license that can be used in OSM and use that to correct the border.
101586376
by sebastic
@ 2021-03-23 16:06
12022-12-01 01:41Rizki IRM-ED
♦129
Hello sebastic. Your edit looks awesome, but I need delete the building due not exist on the imagery (https://maproulette.org/challenge/30233/task/142649605). Thank you.
22022-12-01 04:34sebastic Then go and delete the building. This changeset fixes broken polygons as noted in the comment, whether or not the features actually exist is out of scope.
32022-12-02 01:57Rizki IRM-ED
♦129
Thanks for the response. This is a small mistake because I should be a comment to the first creator and I will make sure better next time. Regards.
119512465
by sebastic
@ 2022-04-09 17:33
12022-04-09 19:04Garmin-User
♦335
Hello,

please have a deeper look at the moved nodes:

https://www.openstreetmap.org/way/41431880#map=17/52.84029/5.96455
https://www.openstreetmap.org/way/876594444#map=18/52.82865/5.92477
https://www.openstreetmap.org/way/200608320#map=15/52.8166/5.9881
https://www.openstreetmap.org/way/200...
22022-04-09 19:11sebastic This changeset triggered conflicts that couldn't be resolved easily, every resolution caused more conflicts.

The changeset couldn't be closed earlier.
32022-04-09 19:17Garmin-User
♦335
I'd revert this changeset. Too much crap happened there. Fuck importer...
42022-04-09 19:27sebastic Should be fixed with the changes in:

https://www.openstreetmap.org/changeset/119515523
https://www.openstreetmap.org/changeset/119515586
52022-04-09 19:34Garmin-User
♦335
Thank you! :)
117215221
by sebastic
@ 2022-02-09 18:49
12022-02-10 17:50E de Wit
♦231
Pandgeometrie moet nog ingemeten worden en staat momenteel verkeerd in de BAG.
Correctie aangevraagd onder terugmeldnummer BAG00099587

Reverted in changeset:
https://www.openstreetmap.org/changeset/117256190

-E de Wit
22022-02-10 18:03sebastic Adres node ligt de change in 117256190 weer in de verkeerde woonplaats.
32022-02-10 18:33E de Wit
♦231
Ah vandaar, dat had ik gemist.
Maar even afwachten wat de terugmelding doet
114182497
by sebastic
@ 2021-11-24 13:29
12021-11-24 23:40Leo Slager
♦3,247
Dag sebastic,
Met het verslepen van de adresnode heb je ook het hele gebouw uit zijn verband getrokken.
https://overpass-api.de/achavi/?changeset=114182497
Het gebouw heb ik weer in oorspronkelijke vorm teruggezet.
22021-11-25 05:38sebastic Bedankt voor de building correctie, bij het downloaden van de adress node waren de gerelateerde ways niet mee gekomen.
111707765
by sebastic
@ 2021-09-26 05:40
12021-09-27 00:38ZeLonewolf
♦559
Hey, just curious if there's documentation somewhere about what "old-style multipolygons" are, how to identify them, and what the fix is?
22021-09-27 03:35sebastic "
Note that before May 2017, some multipolygons also had their tags on the outer way (if there was only one such way or all ways had the same tags) while keeping the respective multipolygon-relation untagged. But when consuming older OSM data excerpts, it is necessary to handle such old style ...
104263410
by sebastic
@ 2021-05-06 15:53
12021-05-23 08:45SomeoneElse
♦13,390
I've removed the name "Q" from https://www.openstreetmap.org/way/938058026 because in the light of https://www.openstreetmap.org/user_blocks/5061 et al it's not very likely!
22021-05-23 08:58sebastic Thanks for your DWG work. The scope of my work on this building was limited to invalid geometries.
103703679
by sebastic
@ 2021-04-27 11:42
12021-05-06 08:47clairedelune
♦55
Through this changeset the Congolese Nord-Kivu province had been deleted. Please note that I have reverted it in order to correct it further.
22021-05-06 08:50sebastic The relation has no members, it is of no value in that state.
32021-05-06 10:01clairedelune
♦55
Indeed it had no member because they had been mistakenly removed from the relation. Adequate fixing of such issue is adding back its members instead of deleting it. Following your changes I've had to repair Nord-Kivu in the DRC and Ugandan Western Region which are admin_level 3 and 4!
42021-05-06 10:16sebastic Deleting relations that are beyond repair is fine. Properly maintained boundaries will get re-added.
52021-05-06 11:27clairedelune
♦55
We obviously have a different understanding of "properly maintained" and of "beyond repair".
62021-05-11 13:15PierZen
♦262
Quality management, «properly maintaining» is to repair. It is quite important to maintain country, region limits. If you go around the world like that and spot such major problems, dont forget that OSM is a community and please contact the country list instead of delete.
104426499
by sebastic
@ 2021-05-10 06:37
12021-05-10 21:18clairedelune
♦55
Dear sebastic, if it's not possible to distinguish locally valuable data damaged by newbies from rubbish which mistakenly got on OSM (and should indeed be removed), please stop "fixing" by deleting all broken polygons in the DRC. I've just had to revert relation 10775396.
22021-05-11 03:55sebastic Broken polygons come in various forms, the solution varies. If you disagree with that, you're welcome to improve upon the fix.

There is no need for changeset discussions, they have little value. Map contributions have much more value.

You'd do well to have the local community involve...
104171964
by sebastic
@ 2021-05-05 08:53
12021-05-10 09:48faustopt
♦33
Please, do not "Fix broken polygons" again. This is wrong. You "split" (again) a group of buildings in te same complex (theatre) originating 6 theatres, instead of 1 whith different buillding altitude!!!
22021-05-10 10:17sebastic Invalid polygon will keep being fixed, if you want to prevent objects you care about to be touched as part of that QA effort you need to ensure they don't trigger QA issues.

Grouping buildings with intersecting ways in a multipolygon relation is an error, that's not a valid use of type=...
101583423
by sebastic
@ 2021-03-23 15:04
12021-04-16 23:15SomeoneElse
♦13,390
For info, I don't think that "Siachen Science Center" http://osm.mapki.com/history/relation.php?id=12480112 is actually a thing. It looks like it's a proposal (see https://core.ac.uk/display/71182480 ) that's as likely to happen as Narendra Modi keeping wicket to Imran Khan...
22021-04-17 05:02sebastic Thanks for your work.

The relation was already there, I just fixed the open rings.

I leave further improvements to the local community.
102191666
by sebastic
@ 2021-04-02 12:02
12021-04-16 14:24Kovoschiz
♦2,543
You broke https://www.openstreetmap.org/relation/12460059 by not adding `building=*` to https://www.openstreetmap.org/way/925188472
22021-04-16 14:33sebastic If you noticed that, why didn't you fix it?
32021-04-16 14:51Kovoschiz
♦2,543
Why don't you wait to see if I'm editing before you make a judgement then? That's an info for you only.
42021-04-16 14:53Kovoschiz
♦2,543
That's not the only problem either, for you are so responsible to ask why I had not fixed it when I comment. Above all, please don't make changesets spanning large areas in the future.
52021-04-16 15:09sebastic Uploading more frequently makes the QA work too tedious, so no. The data is already split into separate countries, that's the best you're going to get.

In the future, don't bother with changeset comments if you're fixing the issue.
102416038
by sebastic
@ 2021-04-06 14:52
12021-04-06 19:49omegla
♦1
https://www.ometv.de
22021-04-06 19:49omegla
♦1
https://chatrulet.de
101879177
by sebastic
@ 2021-03-28 15:41
12021-04-01 12:09rthik007
♦273
Hi sebastic, fixed the alignment based on the imagery Kindly refer to https://www.openstreetmap.org/changeset/102124856.. thank you..
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/101879177
22021-04-01 13:04sebastic That should be fine if the broken polygons have not been reintroduced.
32021-04-05 08:58attili1
♦33
HI Sebastic,
There was a kink which is a sharp angle on an intersection of the highway before, refer https://lh3.googleusercontent.com/-TOHOB8z6KJI/YGqssV9xaFI/AAAAAAAAGbQ/zrGQbrhb_tsG6cqg2-cc5gGP_eQfZWN6QCK8BGAsYHg/s0/2021-04-04.png?authuser=0 which is corrected now. Kindly refer to
https://www....
42021-04-05 09:23sebastic You guys seem pretty active, perhaps you can keep an eye on broken polygons too.

http://tools.geofabrik.de/osmi/?view=areas&lon=122.18701&lat=13.03025&zoom=6
http://area.jochentopf.com/
100984728
by sebastic
@ 2021-03-14 11:14
12021-03-14 17:47nabiladel
♦1
شركة تنظيف بابها
https://alrwnaa.com/%d8%a7%d9%81%d8%b6%d9%84-%d9%80-%d8%b4%d8%b1%d9%83%d8%a9-%d8%aa%d9%86%d8%b8%d9%8a%d9%81-%d9%85%d9%86%d8%a7%d8%b2%d9%84-%d8%a8%d8%a7%d8%a8%d9%87%d8%a7/
100988471
by sebastic
@ 2021-03-14 13:06
12021-03-14 14:24SomeoneElse
♦13,390
Hello sebastic,
It looks like https://www.openstreetmap.org/way/914299745/history was added by someone accused of fictional mapping (see http://resultmaps.neis-one.org/osm-discussion-comments?uid=11940952 ) who I'm now reverting. Can you please check that any edits that you have made have not ...
22021-03-14 14:32sebastic Those roads were connected to buildings with duplicate nodes, and those duplicate nodes were fixed in this changeset along with additional issues reported by the JOSM validator for the changed objects.

Fixing broken polygons is a never ending endeavour, so any reverted fixes are not a big deal.
32021-03-14 14:37SomeoneElse
♦13,390
Thanks - I'll try and tidy up post revert as best I can, but there may still be something that needs local attention afterwards.
26964122
by sebastic
@ 2014-11-23 01:17
12021-02-12 10:20IIVQ
♦136
Hoi Sebastic,

Als ik naar https://www.openstreetmap.org/relation/47516#map=15/53.1660/7.0527 kijk, zie ik dat de suburb Winschoten een kleine (1 boerderij) exclave heeft gekregen in/naast Blauwe Stad. Is dit de bedoeling of een foutje?
22021-02-12 10:41sebastic De exclave rond Verlengde Ekamperweg 4 te Winschoten klopt, zie de BAG:

https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=Winschoten&resultOffset=0&objectId=1895100000006310&geometry.x=266123.492&geometry.y=576952.055&zoomlevel=6&detailsObjectId=18950...
32021-02-18 20:54IIVQ
♦136
Top! Thx voor het checken. (En vreemd)
96128925
by sebastic
@ 2020-12-20 05:38
12020-12-20 08:49Pollux71
♦4
Hello! You have corrected my multipolygon. What did I do wrong? I got some error msg but thought that I corrected them. /Pollux71
22020-12-20 09:53sebastic relation:12039301 had no tags, and its only member (way:886464901) was already present in relation:12039231.
32020-12-20 11:31Pollux71
♦4
Thanks!
26964089
by sebastic
@ 2014-11-23 01:15
12020-10-12 17:59multimodaal
♦269
Hoi Sebastic, ik wilde jou als onze "grensbewaker " even advies vragen aan jou over het volgende:

"Wageningen-Hoog" heeft nu geen aparte boundary of place in OSM, maar wordt algemeen wel gezien als een kern, zie bijvoorbeeld: https://nl.wikipedia.org/wiki/Wageningen-...
22020-10-12 18:23sebastic admin_level=10 is alleen toepasselijk voor officiele BAG woonplaatsen. Wagening-Hoog valt onder de woonplaats Wageningen.

Indien een place node niet voldoende is, en een relation gebruikt wordt voor CBS wijken en buurten kunnen deze beter gemapped worden als boundary=place place=quarter of place=...
32020-10-14 09:58multimodaal
♦269
Hoi, dank voor je reactie. Over het medium: ik weet niet of je een forumbericht zou lezen en zoals je zelf al schreef in het bericht waarnaar je linkte "Ik geen tijd of geduld voor eindeloze discussies" (-;

Deze vraag had kunnen leiden tot aanpassing van de relatie in deze changeset, en...
42020-10-14 10:34sebastic Voor adressering is in de praktijk voornamelijk de postcode van belang, voor Nominatim is de hierarchie van admin_levels van belang en zodoende de woonplaats grenzen.

Binnen een wijk/buurt kunnen meerdere landuses voorkomen, dus een landuse=residential voor de geometrie is niet de meest voor hand...
91478869
by sebastic
@ 2020-09-25 04:33
12020-09-27 12:02SHARCRASH
♦752
Hi!Has this been discussed somewhere? I still get a "duplicate way" error and logically yeah it's 2 ways for the same feature. Personally i don't see the point.

By the way, you had left a also a duplicated natural=water on the outer and inner. Basically you just copied one of...
22020-09-27 13:33sebastic What is there to discuss? old-style multipolygons aren't supported any more, but they still show up on a daily basis.

See the area project for some history:

http://area.jochentopf.com/

I moved the tags from the outer way to the relation so that it's not considered an old-style m...
32020-09-29 09:26Kemps Creek
♦3
@sebastic: Dear sebastic,

quite a few times I've found mechanically fixed or even wrong data – created as old-style multipolygon – and then fixed by you without any attention to it's factual correctness.
In remote regions OSM has basically no quality control and you are the...
42020-09-29 09:35SHARCRASH
♦752
OK by "old style MP" you mean when the tags featuring the area are actually on the outer way instead of being in the relation. So a MP being the inner of another MP and sharing the same ring is totally possible. Really i was not seeing the point in creating another ring to represent the sa...
52020-09-29 10:01sebastic @Kemps Creek, mechanical edits are a bad suggestion, those have even less human oversight.

@SHARCRASH, your scenario suggests that they are two different objects. The nature reserve which can contain other area objects like forest, grass, water, etc. At the time the forest and nature reserve have...
62020-09-29 10:44SHARCRASH
♦752
@sebastic In the anticipation of a change, i agree. My example was bad... But if the outer feature is inherently part of the MP's perimeter, like the fence of a big field with inner elements... i think it would be valid.
72020-09-29 12:09sebastic barrier=fence is a appropriate to put on the outer way if it encloses the same geometry as the e.g. landuse for the outer way of the relation.
77773098
by sebastic
@ 2019-12-01 05:35
12019-12-01 07:33skquinn
♦804
Good catch. I have no idea how this was entered as an "old style" multipolygon but it was clearly not my intent.
75260063
by sebastic
@ 2019-10-04 04:51
12019-10-04 07:12dval
♦426
Hi, sebastic! What does old-style multipolygons mean? Where to read? Show me one before correction.
22019-10-04 07:33sebastic It means relations with only type=multipolygon and no other tags describing the feature e.g. landuse, building, highway, etc.

The wiki briefly mentions this:

https://wiki.openstreetmap.org/wiki/Relation:multipolygon

This QA work is part of the area project:

http://area.jochentopf.com/
70935353
by sebastic
@ 2019-06-04 19:27
12019-09-25 13:40Sowa1980
Active block
Comment not displayed. To view it, please select the "Include blocked users" option.
22019-09-25 14:05Sowa1980
Active block
Comment not displayed. To view it, please select the "Include blocked users" option.
32019-09-26 19:13sebastic Just make sure not to (re-)introduce broken polygons, then they won't show up in the QA dataset, and other mappers won't be inclined to fix them upsetting you again.

If you want details of my changes, inspect the history of the objects in question.
74762984
by sebastic
@ 2019-09-22 04:34
12019-09-22 12:26!bm
♦897
Bitte um kurze Erklärung, was du warum wie geändert hast. Thx!
22019-09-22 12:59sebastic Have a look at the history of the objects to see what changed.

As the comment mentions, old-style multipolygons were fixed, that implies setting tags on the relation instead of the outer way.

See:

https://wiki.openstreetmap.org/wiki/Relation:multipolygon

And:

http://area.jochentopf....
32019-09-22 13:29!bm
♦897
Thx for your edit and fast reply! Now I get it. I hope I don't make the same mistake again. Still wondering why JOSM did not warn me about it—or I might have missed it. --bestregards!bm
---

Published using OSMCha: https://osmcha.mapbox.com/changeset...
74703886
by sebastic
@ 2019-09-20 04:55
12019-09-20 05:49taxi301
♦85
dzięki , nie zdążyłem poprawić , byłeś szybszy
74198519
by sebastic
@ 2019-09-07 06:10
12019-09-08 00:57rivermont
♦221
Hi,
Did you actually check this data before removing it?
I started a multi for an in-progress landcover and even added a note to alert other mappers to its intent.
22019-09-08 06:01sebastic I did. You shouldn't upload invalid multipolygons. Upload it when it's ready. If iD doesn't allow that, switch to JOSM.
32019-09-08 16:52rivermont
♦221
That's probably fair.

But it would be nice if you explained to all these mappers why you are deleting their edits. Most will likely never notice their work is gone, and won't know how to check where it went.

Your changeset comments are also rather misleading; you say you're &quo...
42019-09-08 17:04sebastic I'm fixing objects in the old-style.osm.pbf dataset, which includes relations with only type=multipolygon and no other descriptive tags, the changeset comment reflects that.

See: http://area.jochentopf.com/

If a mapper doesn't notice that his incomplete/incorrect relation is gone, it...
73648530
by sebastic
@ 2019-08-23 05:17
12019-08-23 20:55pkoby
♦110
I noticed that you added landuse=forest to a lot of National Forests. I know for a fact that for Wayne and Allegheny, this tag is incorrect. I recently changed the polygons of these two NFs to reflect the actual USFS land, not the proclamation boundaries (which are not the boundaries of the National...
22019-08-23 21:10sebastic The relations don't have tags describing the feature, mostly just the note: "Nantahala National Forest"

That implies landuse=forest. If it's not than it should be tagged accordingly by someone familiar with the on the ground truth, e.g. you.

As long as these (kind of) relat...
32019-08-23 21:11sebastic "It will be removed sometime in the near future.", why wait. Just delete them now if they can't be tagged appropriately.
42019-08-23 21:42pkoby
♦110
I understand that they don't have descriptive tags. Can I suggest for National Forests, instead of landuse=forest, using boundary=protected_area? That's I think the least number of tags to add that would be accurate, but more can be found here if you'd like to supplement: https://wiki...
71239254
by sebastic
@ 2019-06-14 05:07
12019-07-29 14:42Baloo Uriza
♦2,117
I don't understand why the type was removed here.
---

Published using OSMCha: https://osmcha.mapbox.com/changesets/71239254
22019-07-29 14:47sebastic The relation has no tags, and serves no purpose.

If you want a proper multipolygon relation move the tags from the outer ways to the relation.

See: https://wiki.openstreetmap.org/wiki/Relation:multipolygon
71066976
by sebastic
@ 2019-06-09 09:35
12019-07-19 02:52Sowa1980
Active block
Comment not displayed. To view it, please select the "Include blocked users" option.
22019-07-19 04:45sebastic Invalid multipolygon, touching outer rings most likely.

If you want the details revert to the version before this changeset and run the JOSM validator on the objects.
71456361
by sebastic
@ 2019-06-20 18:15
12019-06-20 19:09SomeoneElse
♦13,390
Ye Gods! 3801 relation changes!

How on earth did you manage to check each one? What did you change in each case?

Best Regards,
Andy
22019-06-20 19:15sebastic JOSM Validator is your friend. It started with fixing broken polygons (inner way outside mostly), then on initial upload there were several easy to fix validator issues. Just removing the deprecated is_in tags doesn't need to be checked for every object.
32019-06-20 19:32SomeoneElse
♦13,390
Using JOSM Validator on a large swathe of objects without any checking by you counts as an automated edit and should follow the automated edits code of conduct set out at https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct .
Don't do it, or you'll be prevented from editing...
42019-06-21 04:20sebastic You can't make volunteers do work. If you want to ensure that I didn't break anything, that's on you.

Block my account if you want to prevent me from breaking anything in the future. You'll need to find someone else to do this QA work and maintain the administrative boundaries...
63478085
by sebastic
@ 2018-10-13 06:24
12018-10-13 22:38Vincent de Phily
♦112
Just adding a fixme tag isn't much of a fix :p ?

Adding that empty relation was a mishap; the feature was already mapped as another object. Fixed in https://www.openstreetmap.org/changeset/63496329
22018-10-14 06:11sebastic There are many more old-style multipolygons in the dataset I process each day, I cannot be bothered to use distrinct changeset comments for each.

Adding the fixme tag ensures that the relation doesn't show up in the old-style dataset, and that it shows up in other QA tools.
32018-10-14 19:44Vincent de Phily
♦112
Moving the problem from one QA category to another doesn't seem that useful ? Arguably harmful in this case: I'd rather be able to look for old-style MPs than digging thru FIXMEs when I do fixup using QA tools, because FIXMEs are way too numerous and diverse for me to handle whereas MP pro...
42018-10-15 05:16sebastic The old-style multipolygon dataset is part of the area fixing effort:

http://area.jochentopf.com/

While the task is marked as done, new old-style multipolygons are still created on a daily basis, and I still fix those.

As I'm fixing many issues, I'm not going to spend time diggin...
52018-10-15 21:28Vincent de Phily
♦112
Fair enough that you can't spend too much time on each issue. I skip a lot of non-trivial issues myself.

But that relation will still show up on QA tools such as Jochen's or OSMI's checkers after you added a fixme, and IMHO the fixme tag doesn't make the issue more visible. I ...
62019-06-20 19:50SomeoneElse
♦13,390
@sebastic Re " I cannot be bothered to use distrinct changeset comments for each" I strongly recommend that you become bothered to do that, otherwise you may find yourself prevented from editing OpenStreetMap.
OSM only works because it is a community, and people within a community have t...
70945685
by sebastic
@ 2019-06-05 06:49
12019-06-08 18:18Diógenes de Sinope
♦187
thanks for the fix 👍🏻 [ https://www.openstreetmap.org/relation/8259302 ] I was really proud of this until it broke
22019-06-08 19:04sebastic You're welcome.

May I suggest using JOSM, it has a much better validator than iD, which greatly helps when editing non-trivial objects like relations.
70112453
by sebastic
@ 2019-05-10 14:34
12019-05-29 18:33takazu
Active block
Comment not displayed. To view it, please select the "Include blocked users" option.
22019-05-29 18:53sebastic Because it wasn't a valid multipolygon, it has touching out rings. A collection of rings like this cannot be modelled as a multipolygon.

The individual rings were tagged with those from the relation to fix the invalid multipolygon.

Why did you not inspect the changes in the object history...
32019-05-29 19:09takazu
Active block
Comment not displayed. To view it, please select the "Include blocked users" option.
42019-05-30 03:45sebastic You should not make assumptions about others.

I fixed the issue in the most appropriate manner, since we don't have a well establish alternative relation type for collections.

If you disagree with changes, you can just revert them and make the changes you see fit. Arguing in changesets is...
68718548
by sebastic
@ 2019-03-31 08:46
12019-05-23 10:37gormur
♦119
What was wrong this multipolygon? Did it warrant outright deleting it?
22019-05-23 10:46sebastic It had no tags after the duplicate tags were removed in the changeset before mine:

https://www.openstreetmap.org/relation/9349785/history
32019-05-23 10:56gormur
♦119
I see. It was that edit was in the wrong. Don't know if you looked into this before you deleted the relation? Reverted.
42019-05-23 11:04sebastic I did, and the change looked sensible, it should have deleted the relation instead of just removing the tags.

With your revert you risk the duplicate information being removed from the relation again.
52019-05-23 11:39gormur
♦119
Sensible? I disagree.

There were two aerodrome objects:
* A multipolygon with several correct tags and outline of the aerodrome.
* A node with fewer tags than the MP.

They both represent the same object but are not exact duplicates. The MP had significantly more information in it.
Then some...
62019-05-23 11:43sebastic You're wrong, removing the relation _is_ a fix for old-style multipolygons. The object won't be detected as an old-style multipolygon again.

Instead of arguing in this changeset, you should have inspected the history yourself and taken the actions you see fit.
72019-05-23 12:07gormur
♦119
It was _not_ an old scool multipolygon...
82019-05-23 12:29sebastic In the context of the area project every relation with only type=multipolygon is old-style.

http://area.jochentopf.com/
70384257
by sebastic
@ 2019-05-18 10:54
12019-05-22 17:04korolenok
♦83
Please, fix the dragged nodes.
https://www.openstreetmap.org/edit#map=16/22.5709/113.4344
---

Published using OSMCha: https://osmcha.mapbox.com/changesets/70384257
22019-05-22 17:08sebastic What are the IDs of the nodes in question?
32019-05-23 09:15korolenok
♦83
Here is a lot of nodes. I can show you IDs of objects
w172967460
r9600331
And osm link on dragged riverbank
https://www.openstreetmap.org/edit#map=18/22.56920/113.43480
42019-05-23 09:28sebastic Disconnecting the node is sufficient to fix this.

Does iD not allow you to do this?

It's fixed with changeset 70519490.
69995781
by sebastic
@ 2019-05-07 19:06
12019-05-09 17:42user_5359
♦19,415
Hello! Please have a detail look on way https://www.openstreetmap.org/way/545658440 : We use english keys (貸衣裳・オリジナルブライダル・写婚 means "Rental costumes, original bridal, wedding") normaly. But I assumed this is more a copy paste error.
22019-05-09 17:45sebastic The tags were indeed copied as-is from the relation. Please go ahead and fix the tagging.
69905931
by sebastic
@ 2019-05-05 14:22
12019-05-05 19:51ファシズム
♦5
Dear sebastic,
what exactly have you fixed here?
Best wishes
22019-05-06 04:29sebastic Various types of broken polygons, see:

http://area.jochentopf.com/

Issues include wrong role for multipolygon members, touching outer rings, duplicate section in polygon, self-intersections, etc.

For these relations it was mostly wrong roles, specifically inner members that were outside th...
69102943
by sebastic
@ 2019-04-11 04:56
12019-04-11 05:06Abdulkadir Çelik
♦20
Thank you, i couldnt figured it out how to do it but you made it :)
22019-04-11 05:08sebastic See the relevant documentation:

* https://wiki.openstreetmap.org/wiki/Relation:multipolygon
* https://josm.openstreetmap.de/wiki/Help/Action/CreateMultipolygon
* https://josm.openstreetmap.de/wiki/Help/Action/UpdateMultipolygon

68533135
by sebastic
@ 2019-03-26 06:00
12019-03-27 11:44hvalentim
♦92
Cool! Somehow it did not seem to work when I tried it back in v11 (castle icon + label did not show when applied to multipolygon - perhaps I should have waited longer) :/
66558971
by sebastic
@ 2019-01-23 06:09
12019-01-23 08:28Ghybu
♦18
Thanks!
66352743
by sebastic
@ 2019-01-16 06:21
12019-01-16 07:32ionr
♦45
Oh, da hab ich wohl doch noch etwas zerhauen. Was war denn kaputt?
22019-01-16 07:43sebastic As you can see in the history of the relation, the landuse tag was removed leaving the multipolygon without tags describing the feature.
32019-01-16 07:51ionr
♦45
Thank you very much for fixing this and your explaination!
66150643
by sebastic
@ 2019-01-09 06:22
12019-01-09 06:44Allison P
♦1,136
Thanks for fixing them. I'm new to OSM and I'm still figuring things out.
65401371
by sebastic
@ 2018-12-12 08:54
12018-12-13 18:41waldhans
♦203
it seems there are some duplicate nodes on the boundary along the 'Bosbeek' like
node 634469456
node 634469335
Please check and correct;
Thank's, Kurt
22018-12-13 19:09sebastic I don't find any issues in the datasets I use (which are limited to the administrative boundaries).

Other features should not be connected the boundaries, so I advise you to move the other features away from the boundaries instead of merging duplicate nodes.
32018-12-13 19:57waldhans
♦203
sorry, I give you step-by-step instructions to reproduce the error:

load node 634464833 in JOSM (Download object...)
load from the slippy map in Josm an area around this point, about 3km along the Bosbeek
now use the Validation tool in JOSM to find the errors

There are at least 12 duplicate ...
42018-12-13 20:13sebastic Those look like disconnected ways resulting from the Replace geometry action.

Because those ways were not modified when the boundary way was replaced, the validator doesn't check them.

I don't consider these nodes a problem as they belong to different ways and should not be nodes sha...
52018-12-13 21:35waldhans
♦203
So you tell me that your JOSM is not reporting multiple errors "duplicate nodes"? If this is true, we should compare the validator .settings!
64724484
by sebastic
@ 2018-11-21 06:07
12018-11-21 07:21Warin61
♦2,666
Hi,
These additions have been from a new mapper .. and they are asking for help...

The building is part of the swimming center ...

See my comments on https://www.openstreetmap.org/changeset/64701712
I think that is better than simply editing?
64430393
by sebastic
@ 2018-11-13 06:21
12018-11-15 11:39Wilmer Osario
♦214
Thanks 😊
63216789
by sebastic
@ 2018-10-05 04:56
12018-10-08 00:45AlaskaDave
♦167
Hi,
What did you change to fix this multipolygon? There is an ongoing discussion about tagging groups of lakes in the Tagging list right now. I thought these "Twin Claderas" might be a similar example but noticed that you had edited it just after I mapped them. I cannot tell from the hist...
22018-10-08 05:18sebastic The old-style multipolygon (with only type=multipolygon tag) with the two members on the left (one outer and one inner) was removed, the correctly tagged multipolygon was updated to also include the inner from the other multipolygon, because it also includes its outer.
62159941
by sebastic
@ 2018-08-31 05:17
12018-08-31 17:53sorcrosc
♦412
The ways you deleted were not old style multipolygons but just untagged geometries I was working on. Please be more careful and don't remove object just because they are not tagged yet.
22018-08-31 18:12sebastic There was no indication that you were working on the relation or its ways. It looked and smelled like a broken old-style multipolygon, hence was removed.

If you want work in progress retrained, you need to tag the elements appropriately.
32018-08-31 21:06sorcrosc
♦412
Sure, It's certainly not my usual workflow.
I'm trying to refine some large poorly mapped landuse and it was late last night.
...but, removing all objects is not the usual way to correct multipolygons
42018-09-01 06:09sebastic Leaving untagged ways not part of any relations also makes no sense.

You don't have to upload unfinished work, you can save the layer and continue later (with or without first updating all elements to sync possible work from other mappers).
52018-09-01 14:57sorcrosc
♦412
I totally agree but I also think map correctors like you should look around a little bit and try to make some good improvement to the map when making a chenge instead of trashing everithing just to clear an error signaled by qa tools. Unused (untagged) relations are harmless by themselfs.
62018-09-01 16:09sebastic When I'm cleaning up QA issues, I'm not in mapping-mode, and won't spend time mapping new features.

Unused relations clutter the database, and add noise to an area where mappers should be able to focus on the features that are being used.
62058282
by sebastic
@ 2018-08-28 05:19
12018-08-28 21:14luschi
♦417
Hi sebastic,
this was not a old-style multipolygon.
I only missed to add the landuse tagging.
So why you added landuse=farmland to this area?
on the part in the est is a oachyard or a vineyard and on the part in the west is a meadow.
If you not make automated edits, you should check the image a...
22018-08-29 05:14sebastic Relations with only type=multipolygon are included in the old-style.osm.pbf dataset I use to fix these issues.

I added landuse=farmland because that what it looks like. Go and improve the tagging as your see fit.
60855304
by sebastic
@ 2018-07-19 05:00
12018-07-30 11:08km2bp
♦285
It's an error . This is not water !!! https://www.openstreetmap.org/way/95203563#map=12/59.4722/9.5821
22018-07-30 11:30sebastic Then please correct the tagging of the relation and its ways.

I just updated the old-style multipolygons.

That water tags came from relation 8457734 which has this way as only (outer) member.

Removing the tags should be sufficient.

Why are you shouting in this changeset instead of removi...
32018-07-31 14:07km2bp
♦285
OK !
60595956
by sebastic
@ 2018-07-11 05:04
12018-07-11 11:11realjep
♦17
Thanks for the correction!
I will try to apply same setting to other important parks around Italy.
47592706
by sebastic
@ 2017-04-09 13:10
12018-04-05 02:09HubMiner
♦271
For nodes:
https://www.openstreetmap.org/node/504619674/history
https://www.openstreetmap.org/node/504619644/history

1) Can we clear out "fixme"?
2) Can we delete all tags for these nodes?
22018-04-05 05:09sebastic The tags for those nodes can be deleted, they are just metadata from a GPS.
32018-04-15 02:31HubMiner
♦271
Do you think wpt_description and wpt_symbol keys should be deleted in global map (after appropriate discussion, approvals, etc)?
42018-04-15 07:14sebastic Probably, yes.
57731214
by sebastic
@ 2018-04-02 07:40
12018-04-02 18:23Jaku103
♦28
Thanks for fixing my work. I was trying to figure that out.
22018-04-02 18:28sebastic The wiki has the reference documentation for multipolygon relations:

https://wiki.openstreetmap.org/wiki/Relation:multipolygon

The tags describing the feature need to be on the relation instead of on the outer way.
32018-04-02 19:08Jaku103
♦28
I have tried many times to do that. I think I have concluded that web ID is flawed and can't do it.
42018-04-02 19:17sebastic JOSM is much more suitable for editing relations.

It has the nice you can easily create multipolygons by selection the outer and inner ways and using the 'Create multipolygon' function, or use the 'Update multipolygon' feature to move the appropriate tags from the outer way to...
53660528
by sebastic
@ 2017-11-10 08:47
12018-03-29 20:14yaugenka
♦151
Please don't delete multipolygons from settlements like this
http://osm.mapki.com/history/relation.php?id=7512159
22018-03-30 05:23sebastic Then tag the multipolygons appropriately so they are not considered old-style multipolygons (with only the type=multipolygon tag on the relation).
32018-03-30 10:10yaugenka
♦151
old-style tagging is not a reason for deleting objects. majority of settlements in our country are tagged in that manner right now and we are improving it gradually.
42018-03-30 10:25sebastic It is when the tags are better left on the ways, the relation has no added value.

If you don't want multipolygon relations to be touched, you need to ensure they have proper tags along with the type=multipolygon.

In this case using a different type than multipolygon is probably more appro...
52018-03-30 11:04yaugenka
♦151
Here are the values which the relation adds:
1. some settlements consists of several separate areas (multipolygons), so putting tags in the ways would cause duplicate settlements.
2. putting tags into ways would render settlement name twice on the osm.org: from the way and label.
3. you can colle...
62018-03-30 11:39sebastic As long as the tags are on the ways and not on the relation it's not a proper multipolygon.

Using a relation to group ways is okay, but using type=multipolygon for the relation is not.

Adding fixme=<some reason> to the relation will keep it out of the data set I use to fix old-style...
72018-03-30 11:47yaugenka
♦151
Can you give link to a wiki page where it says that type=multipolygon for relations is incorrect?
82018-03-30 11:49sebastic https://wiki.openstreetmap.org/wiki/Multipolygon
92018-03-30 12:00yaugenka
♦151
can you give a quote from that page which states that relations with deprecated tags should be deleted?
102018-03-30 12:56sebastic The wiki documents multipolygon relations. Since it's a wiki it can be made to say anything you want. :-)

I'll point you to this instead: http://area.jochentopf.com/old-style-josm.html

You can keep arguing here against the deletion of relations with only type=multipolygon tags, but t...
112018-03-30 13:07yaugenka
♦151
I'm grateful for your help in fixing such relations but the deletions is subject to escalation
47663113
by sebastic
@ 2017-04-11 16:39
12018-03-10 22:17Your Village Maps
♦90
Hi. Could you give me a multipolygons lesson? I know that I created a lot of these old-style ones, but I guess I'm ignorant about the issue. Thanks!
22018-03-10 22:58sebastic In short: don't put tags on the outer way and have only type=multipolygon on the relation, move the tags from the outer way to the relation.

For further reading: https://wiki.openstreetmap.org/wiki/Relation:multipolygon
56891344
by sebastic
@ 2018-03-05 06:27
12018-03-07 06:21MaestroGlanz
♦36
Why that?

Are you from that area to know, if this is indeed used for harvesting timber? If yes, "landuse" is correct, if not "natural" is correct.

Btw. In that case, you must change all the other forests around it either.
22018-03-07 06:25sebastic That's what it looks like on the imagery.

You're free to improve the tagging.

I'm just fixing old-style multipolygons with no tags on the relation.
32018-03-07 06:36MaestroGlanz
♦36
Did I forget the tag?
42018-03-07 06:46sebastic Yes, see version 1 of relation 8076915.
54068029
by sebastic
@ 2017-11-25 09:34
12017-11-25 11:56werst-nouveau
♦1
I created these simply by combining the polygons (fusionner) in the ID editor. If they need to be fixed this seems like an error in the editor, no?
22017-11-25 12:04sebastic Quite possibly, yes.
27841966
by sebastic
@ 2015-01-01 15:15
12017-09-18 23:01Megachip
♦33
Why this is tagged with admin_level 7 but "includes" relations with admin_level 4 and 6? Also it is a bit confusing why only parts of Noord-Holland and Flevoland belongs to AMA/MRA, cause most of the sources tells the whole provinces belongs to the AMA/MRA (e.g. https://www.amsterdameconom...
22017-09-18 23:10sebastic Because the metropoolregio is made up of municipalities (admin_level=8) and provinces (admin_level=4), it replaces the "plusregio" (admin_level=6).

For details of admin_levels in The Netherlands see:

https://wiki.openstreetmap.org/wiki/Tag:boundary=administrative#11_admin_level_valu...
32017-09-20 17:08Megachip
♦33
Thanks for fast reply. Sadly I do not understand dutch very well. Started a german discussion about it: https://forum.openstreetmap.org/viewtopic.php?id=59788
Im thinking about thinks like boundary=economic(al) cause the response of nominatim confuses, how can higher regions belonging to one lower...
42017-09-20 17:53sebastic English is fine on the Dutch forum as well, pretty much all Dutch people speak it unlike German.
46723236
by sebastic
@ 2017-03-09 21:51
12017-09-19 10:05Seandebasti
♦124
hey
how is that possible to intersect the landuse=resid without creating a relation with the wood?
22017-09-19 10:08sebastic Can you be more specific?

relation 6897261 has been deleted by another user in the mean time.
32017-09-19 15:13Seandebasti
♦124
I mean all the wood is away you see if you zoom in from level 16 to 15 that. before your changeset it was all wood, now its just an line with nothing. and because of that alle the small lines (dedicating residential areas) are not in a relation with the missing wood)
I mean you are the last editor ...
42017-09-19 15:16sebastic I fixed self-intersections, but user vnsnt deleted the relation with natural=wood in changeset 51524321, see:

https://www.openstreetmap.org/changeset/51524321

You need to revert this changeset if you want to restore the wood.
47783387
by sebastic
@ 2017-04-14 15:06
12017-09-14 13:17GerdP
♦2,751
Hi!
Please review https://www.openstreetmap.org/relation/5359290
It is now a highway=secondary MP relation, before it was a area:highway=secondary
Same problem here:
https://www.openstreetmap.org/way/360013111
Did you do this change im more places?
22017-09-14 13:58sebastic area:highway doesn't make much sense on a MP relation which is already an area. I've made this kind of change more often while updating old-style multipolygons.
32017-09-14 14:18GerdP
♦2,751
I just try to make up my mind what a highway MP is when it comes to routing.
I found many MP which don't describe the same thing as a way with area:highway does. So I think you removed information.
49324605
by sebastic
@ 2017-06-07 05:23
12017-06-07 16:05jj1bdx
♦3
Thanks!
22017-06-07 18:03sebastic You're welcome.
46961809
by sebastic
@ 2017-03-18 17:19
12017-05-20 19:24MrKooken
♦107
Op de plek van weg 309568632 zie ik in mapnik weergave een zwart blok, misschien een foutje ergens in de multipolygoon?
22017-05-20 20:12sebastic De mapping hier is voor verbetering vatbaar. Ga je gang zou ik zeggen.
32017-05-20 20:44MrKooken
♦107
Ik zou zo niet weten wat hier verder nog voor verbetering vatbaar is, hou me al bezig met 1001 verbeteringen. Ben geen groot talent als het om multipolygonen gaat dus..
42017-05-26 17:22sebastic way:309568632 heeft als tags waterway=canal bridge=yes, op basis van de luchtfoto's lijkt het echter een glijbaan en is dit waarschijnlijk een geval taggen voor de renderer, wat wel meer het geval is in dit waterpark.
52017-05-26 18:09MrKooken
♦107
Het is inderdaad een glijbaan. Zo'n 5m hoog en breed en zo'n 25m lang.
48808503
by sebastic
@ 2017-05-19 03:31
12017-05-21 21:57MarcoR
♦518
With this changeset, you didn't fix old-style multipolygons; in fact the multipolygons were already being mapped with the "new-style".

You just changed some landcover=grass and landcover=trees respectively to landuse=grass and landuse=forest (which is just wrong, since the land as...
22017-05-22 05:48sebastic The old-style multipolygon was next to these areas and I changed their tagging because landcover is not rendered. Feel free to change it back.
32017-05-22 16:12MarcoR
♦518
Thanks for the answer! If there are not "enough" objects with a tag they will never be rendered on map :) it's a vicious circle...

I won't revert your changeset as it's not a big issue but please don't make these conversions from landcover to landuse in the future.
48344189
by sebastic
@ 2017-05-02 18:54
12017-05-09 10:49mueschel
♦6,575
Hi,
this way got rather strange tags, could you check and correct that?
http://www.openstreetmap.org/way/34792962

Cheers, Jan
22017-05-09 11:02sebastic Please adjust the tags as you see fit.

The the tags from the outer way were simply moved to the relation as part of the old-style multipolygon fixing effort.

There is a lot of import data in these regions, that is for the local community to deal with.
32017-05-09 11:18mueschel
♦6,575
Hi,
thanks for the reply. I think the situation is different for this way, have a look to the full history: https://osmlab.github.io/osm-deep-history/#/way/34792962
It was natural=wood until a week ago, then all tags were deleted by someone else and you added some new tags. I don't see that t...
42017-05-09 11:30sebastic There were a lot of duplicate node issues in this area. Those were fixed after the JOSM validator reported the issues before uploading the previously old-style multipolygons.
52017-05-09 17:25mueschel
♦6,575
I guess natural=wood is right and the rest can be removed?
62017-05-09 18:50sebastic The tags seem to imply so, double check with satellite imagery.
72017-05-09 18:55mueschel
♦6,575
Looks fine. I just changed it.
48323870
by sebastic
@ 2017-05-02 05:40
12017-05-02 16:52Greg_Rose
♦175
Hey Sebastic. I need to know what I'm doing wrong with my riverbank polylines and relations. Based on your changes, it appears that as soon as a riverbank is part of a relation, it loses the riverbank tag. Is that correct?
I wasn't aware that I was doing anything incorrectly - you've...
22017-05-02 18:18sebastic The tags are moved from the outer way to the relation. I process the newly introduced old-style multipoloygons on an almost daily basis.

This is part of the area fixing project by Jochen Topf. See: http://area.jochentopf.com/

If a riverbank consists only of a single closed way, having the tags...
32017-05-02 20:18Greg_Rose
♦175
Thx very much for the quick reply and explanation. Just so you know, the script you're running to fix these multipolygons made it appear that I was doing these correctly - I just thought that there was an automatic translation going on (the multipolygon relation would correctly change not long ...
42017-05-02 20:28sebastic I don't use a script, I use the 'Update multipolygon' feature in JOSM. This is a mostly manual process.

Automated edits in OSM are frowned upon, so your edits won't automatically get fixed. Your edits are just easily spotted due to the ongoing area project.

My experience wi...
52017-05-04 19:38Greg_Rose
♦175
Well no worries here - if you see flaws/errors in my work going forward, please let me know. I'll greatly appreciate it!
I'm passionate about doing this right - and I want to make sure I'm not creating more work for others.
48256309
by sebastic
@ 2017-04-29 13:38
12017-04-29 13:46ImreSamu
♦7
Big Thanks for the correction!
22017-04-29 13:50sebastic You're welcome.
48054049
by sebastic
@ 2017-04-23 09:02
12017-04-23 09:25woodpeck
♦2,431
Sebastic, if you delete polygons and someone else undoes your deletion, the correct approach is to discuss the issue, not stubbornly delete them again.
22017-04-23 09:48Kostik
♦55
https://forum.openstreetmap.org/viewtopic.php?id=6129&p=120
32017-04-23 09:55Kostik
♦55
Do not remove the relationship 3767168, 3767169 and the like!
42017-04-23 09:56Kostik
♦55
3919370, 3919098
52017-04-23 10:17Kostik
♦55
4471401
62017-04-23 10:23Kostik
♦55
5372735
72017-04-23 11:18sebastic Please give these relations proper tags so that they don't qualify as old-style multipolygons.
82017-04-23 14:40Kostik
♦55
Before removing something, a good tone to write to the author of editing.
92017-04-23 14:42Kostik
♦55
Is the tag "note" not enough for you?
102017-04-23 14:52Kostik
♦55
I added a tag to the "note:de" for more of your understanding.
112017-04-23 15:31sebastic Neither the "note" nor "note:de" tag is sufficient to not have those relations be considered old-style multipolygons.

If you want to keep those relations in OpenStreetMap you should improve their tagging so they are not considered old-style multipolygons.

I'm not germa...
122017-04-23 16:28Kostik
♦55
If you do not want to roll back your vandal corrections, do not touch my relations.
132017-04-23 17:28sebastic If you don't want people to touch your relations, they shouldn't be in the OSM database that anyone with an account can edit. They should live in your own system to which only you have access.
48053844
by sebastic
@ 2017-04-23 08:52
12017-04-23 10:48Kostik
♦55
Löschen Sie nicht 6227760
22017-04-23 11:19sebastic Please give these relations proper tags so that they don't qualify as old-style multipolygons.
32017-04-23 14:34Kostik
♦55
Is the tag "note" not enough for you?
42017-04-23 14:39Kostik
♦55
Before removing something, a good tone to write to the author of editing.
52017-04-23 15:27sebastic No, the "note" tag is not sufficient to not have those relations be considered old-style multipolygons.

If you want to keep those relations in OpenStreetMap you should improve their tagging so they are not considered old-style multipolygons.
62017-04-23 16:52Kostik
♦55
I do not have enough of your explanation to not roll back your vandalizing!
72017-04-23 17:16sebastic Have a look at this project currently underway:

http://area.jochentopf.com/

On the comparison map, and in the old-style.osm.pbf file, you'll find your relations. If you improve your relations so that they won't be considered old-style multipolygons, neither I nor anyone else working ...
48053806
by sebastic
@ 2017-04-23 08:50
12017-04-23 10:08Kostik
♦55
Löschen Sie nicht 6134725
22017-04-23 11:18sebastic Please give these relations proper tags so that they don't qualify as old-style multipolygons.
32017-04-23 14:39Kostik
♦55
Before removing something, a good tone to write to the author of editing.
42017-04-23 15:31sebastic Likewise for reverting edits.

If you want to keep those relations in OpenStreetMap you should improve their tagging so they are not considered old-style multipolygons.
52017-04-23 16:23Kostik
♦55
I added a tag to the "note:de" for more of your understanding.
48053821
by sebastic
@ 2017-04-23 08:51
12017-04-23 10:42Kostik
♦55
Löschen Sie nicht 3371968
22017-04-23 11:18sebastic Please give these relations proper tags so that they don't qualify as old-style multipolygons.
32017-04-23 14:39Kostik
♦55
Before removing something, a good tone to write to the author of editing.
42017-04-23 15:29sebastic Likewise for reverting edits.

If you want to keep those relations in OpenStreetMap you should improve their tagging so they are not considered old-style multipolygons.
47571523
by sebastic
@ 2017-04-08 15:55
12017-04-11 08:30dudka
♦284
did you run any script or made changes one by one reviewing each multipolygon?
22017-04-11 10:16sebastic I iterate over the relations one by one using the JOSM todo plugin.
32017-04-11 11:10dudka
♦284
for buildings please also replace ways by multipolygons in associatedStreet relations
46551152
by sebastic
@ 2017-03-03 15:22
12017-04-10 01:52FTA
♦201
Hi sebastic,
It looks like you deleted the full relation of this university in your changeset (http://www.openstreetmap.org/relation/3744410). The way you added tags to (http://www.openstreetmap.org/way/281974224) is only one part of the full campus. Please try to be a bit more careful in the futur...
22017-04-10 05:37sebastic The relation was invalid and broken beyond repair. Having it recreated by someone else was exactly my intent.
47323455
by sebastic
@ 2017-03-31 12:16
12017-04-03 02:41nyuriks
♦145
hi, thanks for adding wikipedia tags! Please use the Wikipedia plugin to also fetch the corresponding Wikidata tags - makes it very useful for many quality and usecases. Thanks!
22017-04-03 16:18sebastic I only moved the tags from the outer ways to the relation.
47299272
by sebastic
@ 2017-03-30 17:14
12017-03-30 20:15emvee
♦369
Hi Sebasic,

Goed bezig; ik was ook bezig maar toen ik wilde uploaden kwamen er allerlei conflicten op dus ben ik maar richting Duitsland verhuist ;-)

Groeten,

Martin.
22017-03-30 20:56sebastic Yeah, I'm working my way up the old-style.osm.pbf issues per country. Belgium had the smallest file size now. I think I can thank you for making that happen. :-)
47163503
by sebastic
@ 2017-03-25 21:49
12017-03-27 08:39Carnildo
♦905
Could you do this in smaller chunks? I suspect this changeset is responsible for deleting the banks of the Columbia River between John Day Dam and McNary Dam, but it's such a huge changeset that none of the usual review tools works well with it.
22017-03-27 08:58sebastic The tags we simply moved from the outer ways to the relation.

Can you be more specific (e.g. map link) where between John Day Dam & McNary Dam the riverbanks are missing?
32017-03-27 17:59Carnildo
♦905
I've fixed it already, but about ten hours ago, the ways making up the relation created in https://www.openstreetmap.org/changeset/47194830#map=9/45.8153/-119.9671 had no tags and were not part of any relation. However, stale rendering of map tiles showed that they had recently been tagged and...
47077291
by sebastic
@ 2017-03-22 19:49
12017-03-23 05:03nyuriks
♦145
Hi, thanks for adding wikipedia tag. Please install "wikipedia" plugin, and use "fetch wikidata IDs" too - it will add both wikipedia and wikidata tags for you. Thanks!
22017-03-23 07:13sebastic I only moved the tags from the outer ways to the relations. The wikipedia tag was already present on the outer way.
46960750
by sebastic
@ 2017-03-18 16:34
12017-03-20 15:49MrKooken
♦107
I don't see any change. Like to know what an "old style" multiploygon is...
22017-03-20 16:11sebastic The multipolyons are rendered the same. For more information, see:
http://area.jochentopf.com/
32017-03-20 16:48MrKooken
♦107
Thanks.
24558382
by sebastic
@ 2014-08-05 15:32
12017-02-17 20:12eggie
♦40,705
Hoi, Een nieuw mapper heeft hier aan de adm. boundery gezeten. De laatste revert mislukte wegens te veel conlicten. 'k Weet dus niet of-ie nog goed ligt.
http://overpass-api.de/achavi/?changeset=46171197
Groet,
Eggie
22017-02-17 20:54sebastic De way leek nog goed te liggen, waarschijnlijk waren alleen non-boundary objecten aan de boundaries geknoopt. Voor de zekerheid heb ik het segment geupdate m.b.v. de officiele geometrie.
32017-02-17 21:03eggie
♦40,705
klopt.. er zat een pad aan vastgeplakt. Dat heb ik verwijderd.
31883029
by sebastic
@ 2015-06-10 21:00
12015-06-17 08:10waldhans
♦203
Thank's for destroying the boundary DE/NL! Can you tell why you did this? The boundary was defined by the most precise informations, and you changed it without checking or asking into something. What source did you use?

If possible, revert the changes ASAP.
22015-06-17 08:49sebastic > Thank's for destroying the boundary DE/NL!

Thanks for your constructive feedback. Your passive aggressive stance is very motivating.

> Can you tell why you did this?

Because I maintain the administrative boundaries of the Netherlands using the official government open data.

...