Conclusie: het per ongeluk aanpassen van grenzen kan je alleen maar voorkomen door het bij de basis grondig aan te pakken.
Als je editrechten per elementtype wil invoeren in JOSM en iD denk ik dat je dat bij hen zou moeten aankaarten.
Zeker dat is de manier om ‘ongelukjes’ maar ook opzettelijke edits in de toekomst te voorkomen en denk dat je dan al 99% van alle afwijkingen die je nu tegenkomt preventief afdekt. Doe je dat niet dan kom je in de grijze zone terecht: we zien de afwijking maar hoe nu weer goed herstellen.
Richting iD-editor kan ik wel een balletje opgooien om te kijken of aanpassingen opgepakt kunnen worden zodat ik middels iD-editor dan tests kan uitvoeren…
JOSM zal iemand anders op moeten pakken.
Het is heel goed grensverschillen te constateren, echter als er dan daarna niets meegedaan wordt kwa actie is het mijnsinziens tijdverspilling…
Bovendien: dat wat hier in Nederland geconstateerd wordt aan afwijkingen in OSM is wereldwijd & daardoor universeel van toepassing. Des te meer reden het ECHT in de basis af te vangen toch ?
Maar misschien zijn er nog betere oplossingen daarom wacht ik nog even op reactie’s van anderen.
Er zijn historic=boundary_stone gekoppeld aan de grenslijn.
De vraag is dan op basis van wat gemapt
- luchtfoto
- bij stone aanwezige lat lon
of gekoppeld aan grenslijn, laten staan of verschoven, op basis van luchtfoto.
1 Like
Laten we niet vergeten dat grensstenen, hoe tegenstrijdig dit ook mag klinken, zeker niet altijd de precieze ligging van een (stads)grens aangeven. Het verschuiven van grenzen op basis van een luchtfoto is daarmee kwestitieus.
BAG is ook niet perfect. Ik heb in het verleden bijvoorbeeld dit hoekpunt van de grens met België opzettelijk handmatig versleept. Volgens BAG zou dit op de westelijke rand van de rijbaan moeten liggen, maar zowel de markeringen op het asfalt als de Vlaamse gewestkaart geven aan dat het punt dicht bij het midden van de rijbaan ligt.
Ik vraag me af hoe satellietdataportaal zijn landsgrenzen bepaalt, Immers zij zijn verplicht alleen fotomateriaal in beeld te brengen wat Nederlands grondgebied betreft. Wellicht ligt daar het correcte correctie antwoord ?
Maar dan nog als het 100% hersteld is, garandeerd dat dan dat het correct blijft ?
Inderdaad vreemd. Bekeek net omgeving Baarle Nassau. Sommige datums houden de grens aan , andere datums gaan wel de grens over……
Voor het repareren van (woonplaats)grenzen kan je mij vragen de betreffende woonplaats(en) opnieuw te importeren.
Ervaren mappers kunnen dat ook zelf als ze mijn exports weten te vinden.
2 Likes
Ik vermoed een combi van mensenwerk, onvolmaakte software en dataoverdrachtproblematiek (nee, dat is geen mooi scrabblewoord, want het past niet op het bord).
Blijft een wiebelige oplossing want:
- Je kan pas wat vragen als je echt bijna 100% zeker weet dat grenzen veranderd zijn of op zeer korte termijn gaan veranderen anders krijg je verzoeken die achteraf niet nodig blijken te zijn.
- dan moet je wel lid zijn van dit OSM-NL forum, overgrote deel wat (per ongeluk) foutieve edits doet is dat niet.
Je kan er ook voor kiezen je niet druk te maken over het feit dat de administratieve grenzen in OSM niet 100% overeen komen met de bestuurlijke grenzen. Iedereen kan de grenzen in OSM bewust of onbewust aanpassen, dat actief patrouilleren is m.i. niet de moeite waard.
Als de verschillen je teveel storen omdat je op het spectrum zit bijvoorbeeld, ontwikkel dan een QA systeem wat de twee data bronnen analyseert, de verschillen inzichtelijk maakt, en met JOSM integreert om de OSM data bij te werken.
1 Like
Sorry, dit vind ik te ver gaan. Het is niet bijzonder om fouten te willen oplossen en voorkomen. Kun je dat een beetje anders formuleren?
1 Like
In de tussentijd, constructief blijvend, grenswijzigingen opgedoken via cbs gegevens middels gemeente landoppervlak toe en/of afname.
De grenswijziging Haarlem-Velsen is hier al eens aangekaart en verwerkt maar zijn de grenswijzigingen:
- Rheden ↔ Brummen 2x (Gelderland)
- verder is op termijn ook dit document van belang aangaande op stapelstaande gemeente fusie die, als alle stappen positief afgerond zijn, 2030-01 dan plaats gaat vinden.
- Koggenland ↔ Hoorn (Noord-Holland)
- Leidschendam-Voorburg ↔ Den Haag 2x (Zuid-Holland)
dat ook Sebastic ?
Ik zit zelf op het spectrum en kan zodoende goed begrijpen waarom iemand die verschillen niet los kan laten. Ander taalgebruik zie ik geen noodzaak toe, want er staat m.i. niets problematisch. In de post van Dillen_GJ wordt gezocht naar een structurele oplossing, dat is wat ik voorstel.
De CBS gemeentelijke indeling beschrijft alleen de koppeling tussen gemeentes en provincies, niet de geometrie. Omdat gemeentes verplicht zijn hun oppervlak in aansluitende woonplaatsen te verdelen worden geometrie wijzigingen aan de gemeentegrenzen ook via de woonplaatsgrens updates in OSM opgenomen.
Of de drie specifieke wijzigingen ook al in OSM verwerkt zijn kan ik niet zeggen, wat ik wel kan zeggen is dat alle woonplaatsgrens wijzigingen elke maand verwerkt worden. Wanneer gemeentes voor de betreffende wijzigingen hun woonplaatsgrenzen in de BAG niet hebben bijgewerkt, dan ontbreekt die wijziging aan de gemeentegrens in principe ook in OSM.
Als je wilt verifiëren of die drie wijziging verwerkt zijn, achterhaal dan de betreffende woonplaatsen waar de geometrie is gewijzigd, en bekijk de history van de betreffende way en/of boundary relation in OSM of daar dit jaar BAG updates voor uitgevoerd zijn. Changesets voor mijn updates hebben de comment: “Update boundary (level 10) for ”.
Klopt maar kan wel gebruikt worden als lead-info (kanarie in de kolenmijn methode) zodat je vandaar uit gericht op zoek kan naar geometrische wijzigingen in (gemeente) grenzen.
Deze methode is 100% foutloos omdat bijv. hiermee óók gewonnen land uit water zichtbaar wordt.
‘Just my 2 cents worth’-opmerking.
Is dat nog nodig, als sebastic alle gemeentegrenzen maandelijks verwerkt?
Ja, het fietspad is nu de grens.
1 Like