Administratieve grens verwijderd door relatief nieuwe mapper

Een nieuwe mapper vindt het niet nodig dat er een administratieve grens is rond Den Haag
https://www.openstreetmap.org/changeset/91004144#map=12/52.0750/4.3037

https://overpass-api.de/achavi/?changeset=91004144

Quote : Woonplaats heeft alleen zin als het een onderverdeling is van gemeente.

Wat doen we hiermee?
Geen reactie van mapper

edit… Ook wordt er nu in hoogtempo van alles aan de klassering van de trambanen gedaan. Met editor iD
edit2 Inmiddels reactie… zie changeset

Gemeenten kunnen een woonplaatsbesluit nemen waarbij het gehele grondgebied uit slechts één woonplaats bestaat. Dan zijn de gemeentegrens (admin_level=8) en woonplaatsgrens (admin_level=10) dus gelijk. Het was dus correct gemapt en deze wijziging zal teruggedraaid moeten worden.

In de andere edit wordt de tramroute van tram 3 en 4 in route=light_rail gewijzigd. Deze tag wordt nauwelijks ondersteund. Daarnaast is lightrail een heel scala van ov-typen tussen een tram, metro en trein. In dit geval gaat het om een sneltram, die dezelfde trams gebruikt als bijvoorbeeld tram 19. Die laatste is echt geen lightrail.

Nieuwe Mapper hier!

Zojuist gereageerd, maar eggie was snel met posten. Voor het gemak alles wat ik aan eggie gestuurd heb:

“Per de documentatiepagina gaat admin level 10 over woonplaatsen als onderverdeling binnen een gemeente. Die kent Den Haag niet. Ik heb ervaring met databeheer en wikipedia, en duplicate data leiden tot meer dataverbruik, meer onderhoudswerk en meer fouten. Dus vandaar. Maar als het de conventie is om altijd voor zowel gemeente als woonplaats een way te hebben, kan ik hem wel undo’en/opnieuw maken. Dan zet ik meteen een notitie bij de documentatie,”

Even simpel gesteld: ik vind het vreemd en onverstandig om onderverdelingen te mappen die er niet zijn. Is ook niet nodig, ik heb even in Duitsland gecheckt, en daar is het grootste deel niet tot level 10 onderverdeeld, maar afhankelijk van de situatie.

Voor de duidelijkheid: Ik realiseer me nu wel dat ik tegen het gebruik van OSM in NL mappers in ben gegaan, en zal voortaan beter checken en een voorstel doen op het forum of de overlegpagina voor ik dingen verwijder.

Groet,

Maarten

De betreffende changeset heb ik voorlopig teruggedraaid middels deze revert https://www.openstreetmap.org/relation/192737#map=12/52.0751/4.3039
Maarten The Mapper is van harte uitgenodigd op het forum.

Maarten… Welkom op het forum…
Wellicht komen er nog tips van ervaren mappers hier.
Je kunt altijd in de historie kijken wie de voorgaande mapper is en evt. navragen waarom iets op een bepaalde manier is getagd.
Kijk svp ook nog even naar die tramlijnen.
In ieder geval bedankt voor je reactie…

Dankjewel!

M.b.t. die tramsporen: Zoals https://wiki.openstreetmap.org/wiki/Tag:railway=light%20rail?uselang=nl ook al aangeeft is het onderscheid niet eenduidig. De criteria uit die pagina die ik daarvoor heb gebruikt zijn 1. dat de baan daar verhoogd ligt en 2. er tussen het overpad bij Oostinje en het centrum geen kruisend verkeer is.

Voor lijn 3 en 4 geldt dat ze voor het overgrote deel over sporen gaan die als light_rail geclassificeerd zijn. Bij gebrek aan criteria in de documentatie lijkt me dat de meest logische. Voor 2, 6 en 19 geldt dit niet, dus die zou ik als tram houden.

Andere landen zijn geen leidraad voor hoe in Nederland met administratieve grenzen omgegaan wordt, vrijwel elk land is anders.

De twee relaties representeren een ander object, de een is de geometrie van de gemeente de ander van de woonplaats. Deze kunnen onafhankelijk van elkaar veranderen (hoe onwaarschijnlijk dat ook is). De relaties hebben geen identieke tags omdat het niet hetzelfde object betreft.

Daarnaast hebben data consumers geen weet van het feit dat geometrie van de woonplaats 's-Gravenhage (op dit moment) gelijk is aan die van de gemeente. Zijn kijken slechts naar de hierarchie van admin_levels. Wanneer de admin_level=10 relatie verwijderd is, heeft de gemeente geen woonplaatsen meer wat effect heeft op adressen welke in principe geen addr:city tag hebben omdat dit afgeleid kan worden van de admin_level=10 relaties waarbinnen de objecten vallen.

Gevallen als dit zijn een reden waarom (nieuwe) mappers niet zomaar alles zouden moeten kunnen editten voordat ze aangetoont hebben te snappen waar ze mee bezig zijn. Helaas heeft OSM nog geen competentie gebaseerd permissiemodel, en is de sturing van ervaren mappers als eggie essentieel.

De uitbreiding van de railway=light_rail, dus de infrastructuur, lijkt me goed gedaan. Er waren een aantal losse eindjes die inderdaad tot het sneltramtracé gerekend kunnen worden.

Wat betreft lijn 3 en 4, dus de ov-diensten, wordt in Nederland de tag route=light_rail niet gebruikt. Alle metrolijnen hebben route=subway en alle (snel)tramlijnen hebben route=tram. Dit geldt ook voor de sneltramlijnen in Utrecht die geheel over railway=light_rail lopen.

De tag route=light_rail wordt niet algemeen ondersteund en daarnaast wordt in Nederland nog steeds een duidelijk onderscheid gemaakt tussen trams en metro’s. Zelfs op het deel van de RandstadRail waar tram en metro samenlopen, zie je dat de trams (3 en 4) een lage instap hebben en de metro’s (E) een hoge instap. Daarnaast heb je het verwarrende systeem dat je voor de metro buiten in moet checken en voor de tram binnen. Verschil is er dus duidelijk.