Voor consistentie en uniformiteit zou ik het zo uitvoeren:
crossing=zebra / crossing_ref=zebra + crossing:markings!=zebra aanpassen naar crossing:markings=zebra
overige crossing=zebra / crossing_ref=zebra zonodig aanvullen met crossing:markings=zebra
crossing=marked zonodig aanvullen met crossing:markings=yes (voor toekomstige Maproulette missie)
crossing=unmarked zonodig aanvullen met crossing:markings=no (kan ook zeker een Maproulette missie gebruiken!)
crossing=controlled omzetten in crossing=traffic_signs
crossing=traffic_signs zonodig aanvullen met crossing:signals=yes
crossing=uncontrolled zonodig aanvullen met crossing:signals=no
( met “zonodig” bedoel ik: als de tag het er nog niet is)
En dan kan je alle gewenste crossing=* waarden afleiden van combinaties van de twee crossing:* tags, als je daar eenduidige afspraken over kan maken. Er kan dan geen informatieverlies meer optreden, en het is voor data users wereldwijd eenduidig, zelfs als ze andere conventies voor de crossing waarden hanteren.
Ik ook, blijkt. Kan je nagaan hoe vaak ik OsmAnd voor autonavigatie gebruik…we hebben een TomTom in de auto, die doet dat standaard niet maar kan het vermoedelijk wel.
Interessant is welke OSM-tag(s) OsmAnd gebruikt hiervoor. Ergens is een spec voor de transformatie van OSM-data naar de OsmAnd minidatabase, en daarin moet dat wel staan. Toch eens nakijken.
PS Ik denk dat dit het is, in een bestand poi_types.xml dat tijdens het aanmaken van de OsmAnd-kaart toegepast wordt:
<poi_type name=“highway_crossing” tag=“highway” value=“crossing” no_edit=“true”>
<poi_additional_category name=“highway_crossing_type”>
<poi_additional name=“crossing_traffic_signals” tag=“crossing” value=“traffic_signals”/>
<poi_additional name=“crossing_uncontrolled” tag=“crossing” value=“uncontrolled”/>
<poi_additional name=“crossing_unmarked” tag=“crossing” value=“unmarked”/>
</poi_additional_category>
<poi_additional_category name=“tactile_paving”>
<poi_additional name=“tactile_paving_yes” tag=“tactile_paving” value=“yes”/>
<poi_additional name=“tactile_paving_contrasted” tag=“tactile_paving” value=“contrasted”/>
<poi_additional name=“tactile_paving_primitive” tag=“tactile_paving” value=“primitive”/>
<poi_additional name=“tactile_paving_incorrect” tag=“tactile_paving” value=“incorrect”/>
</poi_additional_category>
</poi_type>
Ik maak eruit op dat OsmAnd een highway=crossing als een POI ziet, en die kan hj benoemen tijdens de navigatie. Hij kijkt alleen naar de node, niet naar de kruisende wegen, en maakt geen onderscheid in fietsoversteken, voetoversteken en andere oversteken. Hij geeft als gegevens door: traffic_signals OF uncontrolled OF unmarked (uit de crossing tag) en de tactile paving types.
In principe weet OsmAnd dus niet wat er kruist en of het een zebra is, alleen of er verkeerslichtaansturing is en indien dat niet bekend is, of de oversteek ongemarkeerd is. De waarde crossing=zebra kent-ie niet en soorten markeringen ook niet.
De highway=crossing kan in de navigatie aangekondigd worden, theoretisch de extra gegevens ook maar ik zie daar geen parameters voor: hij noemt dus gewoon alle crossings “zebrapaden” in de NL locale.
Dus ook de fietsoversteken.
Het ijkt erop dat crossings voor de routering niet gebruikt worden, laat staan dat er gekeken wordt wat wat kruist. Niet onlogisch, want een auto routeren ze zowizo niet over een fietspad of voetpad. Daar heb je de crossing node niet voor nodig.
Ik vind dit ook best een acceptabele oplossing. In de basis kan je met 1 tag af voor de meeste simpele situaties.
Het enige waar ik me aan stoor (en dat ligt niet aan Peter, maar gewoon deze chaos), is dat we dan nog steeds twee systemen hebben. Én crossing=traffic_signals én crossing:signals=yes. Ik zou zeggen we kiezen 1 van de 2 en de ander verwijderen we gewoon. Ik vind dat we best als NL community hier gewoon een keuze in mogen maken en zeggen dat we de ander niet ondersteunen.
In zekere mate geldt dit eigenlijk voor alle crossing=* als we alles vangen in de subtags.
Nodig? Nee. Maar dit is een simpele foute tagging, en crossing=traffic_signs wordt door veel mappers nodig geacht, dus zou ik het voor nu gewoon veranderen in wat bedoeld was, en dat erin laten staan.
Idem voor de andere crossing=* tags: laten staan zolang het nodig/nuttig geacht wordt, bv crossing=zebra als ducktag voor zebra, en voor de consistentie de crossing:* tags toevoegen. Dan wordt het osm-breed consistent en eenduidig en blijft dat ook als er diverse hierarchische logica’s in de crossing key toegepast worden.
Dit is nu mijn duck-tagging voor toe te voegen zebra’s (control-V N zet de nieuwe node aan de way.)
Voor al gemapte crossings die alleen geen zebra-tag hebben, gebruik ik hem ook: Control-V M merget de tag erbij.
Alleen als er al crossing:markings=yes getagd was, moet ik yes in zebra veranderen. En af en toe een die ten onrechte crossings:markings=no of dots of dashes zegt, maar dat is ook een signaal om even op recente satellietbeelden te kijken).
Over dots alleen bij voorrang op de fietsoversteek:
Vandaag had ik er eindelijk eentje die dat niet toepast:
De fietskruisingen zijn getagd als uncontrolled en bicycle=yes. Ik denk dat hier bicycle=designated de situatie beter zou weergeven (het is een aangewezen oversteekplaats voor fietsers). Maar daar kom ik verder niet aan.
Oef, 't onderwerp is flink gewijzigd. Misschien de berichten betreffende hoe-te-taggen / zebra’s omtaggen afsplitsen van het oorspronkelijke “NDW dataset” topic?
Daarnaast een vraagje betreffende het oorspronkelijke NDW-topic: is er een manier om (zonder dummy-tags toe te voegen zoals note="Alsjeblieft geen zebra toevoegen, zebra is echt verwijderd, trust me) vals-positieven aan te geven in de kaart van @PeeWee32 ? In Nijmegen is een aantal (begin november èn begin dit jaar) verwijderde zebra’s al meermaals opnieuw toegevoegd (en teruggedraaid) in de afgelopen weken…
Iets met disused of razed of zo? Dat zou dan door de verwijderaar gezet moeten worden, en de verwerking aangepast, dan verschijnt die zebra helemaal niet op de kaart.
Ik denk dat die dummy node van Peter de enige oplossing is om de zebra niet meer te tonen op mijn kaart. Het toevoegen van data obv dit soort (niet 100% actuele) kaartjes is helaas een probleem als er recent iets gewijzigd is. Dat geldt b.v. ook voor sateliet imagery. Ik zie helaas geen andere oplossing.
Het zijn er nu 903 verspreid over het land, en ik kom nog steeds veel valspositieven tegen. Na deze actie (ja, die komt helemaal af, zelfs als ik het vrijwel in mijn eentje doe), kan de lijst apart opgeslagen worden en aan de bronhouder aangeboden worden om de AI te trainen of zo. Heel veel zijn punaises, die zouden er echt niet in mogen zitten.
Mocht er dan ooit een volgende ronde komen dan kunnen we checken of de valspositieven eruit zijn, en zo niet misschien iets bakken met de aparte lijst ipv met tags in OSM. Overigens, de informatie in die tag klopt wel, dus helemaal dummy is hij niet. Het is niet tralala=tralala, of peter=gek.
In de standaardstijl van JOSM is een crossing altijd een wandelmannetje. Dat het technisch anders kan laat de road extended plugin zien; maar dat wordt niet overgenomen in de standaardstijlen van belangrijke toepassingen. belang/tijd-afweging denk ik.
Iets met disused of razed of zo? Dat zou dan door de verwijderaar gezet moeten worden, en de verwerking aangepast, dan verschijnt die zebra helemaal niet op de kaart.
Tsja, de verwijderde zebra’s waren verwijderd op 7 april en 4 november jl., dus nog vóór deze challenge begon. Dus tenzij ik bij elk object dat ik ooit verwijder “was:highway=crossing”, “was:natural=tree” etc ga taggen, was het onmogelijk om in de toekomst te kijken om dit te voorspellen .
(Nog even los van of geheel verwijderde objecten op de kaart moeten blijven staan, en duidelijke vals-positieven toch getagd moeten worden, daar heb ik een mening over, maar dat terzijde. Ik begrijp nl. dat deze tags tijdelijk zijn, dus zolang ik niet gedwongen wordt ze te plaatsen om tegen het script te vechten over wat werkelijkheid is )
Ik zie helaas geen andere oplossing.
Wellicht een paar ideeën, zonder te weten of ze technisch uitvoerbaar zijn:
Natuurlijk idealiter een vals-positief knop op de kaart
Wellicht een automatische vergelijking met de status van OSM op de datum waar de dataset vanaf stamt? Als dit PDOK 2023 was, en er op de eerste vliegdatum wel een zebra stond getagd, dan is het zeer waarschijnlijk tussendoor verwijderd omdat de echte zebra ook verdwenen is
Of (maar dit is wrs lastig als de node echt weg is) de geschiedenis van de dichtstbijzijnde node bekijken of er ooit een zebra stond? Of iets makkelijker, maar ook iets gemakkelijker vals-negatief: van alle wegen binnen (zeg) 10 m van de vermeende oversteek kijken of ze gewijzigd zijn sinds de data van de dataset ingewonnen is, en zo ja hier niets melden?
Gewoon ideeën, maar hopelijk is er iets uitvoerbaar
Het lijkt te gaan lukken om de tijdelijkheid terug te brengen tot 1 dag. Gisteren heb ik 4 van die al wekenlang bestaande tags (op “punaises”, die worden heel vaak als zebra gemeld) verwijderd uit Yerseke, en vandaag toont de ververste zebrakaart ze niet als zebra.
Nog even testen of het ook goed gaat met nl_no_zebra tags die ik vandaag toevoeg, die zou ik dan morgen moeten kunnen weghalen en dan overmorgen kijken of ze niet ineens weer op de kaart verschijnen.
Het weghalen van die tijdelijke tag is technisch gezien een mechanical edit, maar ik ga ervanuit dat dit niet de hele ME-procedure hoeft te doorlopen. Ik kan in de changesets linken naar deze draad.
Ik zou niet weten hoe ik dit voor elkaar kan krijgen want de melding moet ook ergens opgeslagen worden en waar is dat en heeft iedereen daar toegang? Ik zou het niet weten hoe dit eenvoudig op te lossen is.
Dit vereist toegang tot historische OSM data en dat heb ik helaas niet. Al mijn OSM data wordt in principe (dagelijks als het goed gaat) opgehaald uit netherlands-latest.osm.pbf en dat is actueel OSM NL.
Zie 2
We hebben het nu “opgelost” (met dank aan andere Peter voor het idee) doordat ik lokaal op mijn PC de false_positives opsla en niet meer verwijder. Ze worden wel op het kaartje getoond waarbij aangegeven wordt of ze wel op niet (y/n) nog op OSM aanwezig zijn. Als ze daar getoond worden kunnen ze in principe uit OSM verwijderd worden maar we willen het nog een paar dagen aankijken of het zo werkt. Als dat zo is kunnen alle false_positives die op het kaartje staan verwijderd worden uit OSM. Op deze manier staan ze heel kort in OSM.
Uiteraard valt er wat af te dingen op deze methode maar biedt wel perspectieven om OSM relatief eenvoudig te verrijken. Het alternatief vergelijkbaar met disused:highway zou ook kunnen maar heeft ook wat nadelen.
De 4 weggehaalde note-tags in Yerseke, die nodes bestaan nog (zonder tags) maar ik zie ze niet op het QGIS-kaartje (alle lagen aan).
Voor mij is nu het belangrijkste dat ze inderdaad niet meer als ontbrekende zebra’s getoond worden. MIjn project is: de kaart leegmaken!
Het klopt dat die lagen in de URL zit. Dat werkt lekker als je een bookmark wil maken maar als de kaartenmaker dan wat wijzigt kan het zomaar zijn dat je dingen mist. Ik neem maar even aan dat het probleem nu opgelost is. Succes verder met mappen van de zebras
@Allroads Denk jij dat NEO dit gaat herhalen of bijwerken? Dan is onze informatie over vals-positieven belangrijk voor hen om hun AI aan te passen zodat-ie minder fouten maakt. Geen enkele wegbeheerder zit te wachten op een bestand met zoveel knullige fouten, toch?
En wat hebben wegbeheerders aan een bestand met verdwenen zebra’s, die hebben ze immers zelf weggehaald!
.
)