Ik zie nog steeds niet in waarom de lengte van een relatie in de tagging opgenomen moet worden. De lengte volgt automatisch uit de geometrie van de relatie. Het aanmaken van een tag zorgt er alleen maar voor dat afnemers van de data lui worden. Ook bestaat er een grote kans dat de informatie niet uptodate is met de daadwerkelijke lengte van een relatie want je bent afhankelijk van hoe vaak een script de relaties bijwerkt.
Ik vind het automatisch aanpassen van tags door bots zinloos (op het corrigeren van duidelijke typfouten na) en een potentiele bron van problemen en ergenis.
Zo zijn er bots die bijvoorbeeld highway=gate omzetten naar barrier=gate puur op basis van het feit dat iemand in de wiki pagina gezet heeft dat gate tegenwoordig bij de barriers hoort. Terwijl highway=gate al jaren zo getagd wordt en dus renderers en andere afnemers daarmee werken wordt zo even door 1 iemand/script bepaald dat het anders moet.
Nu is het vorige voorbeeld nog niet heel erg maar straks komt er een bot die wegen aanelkaar koppelt als er een node vlakbij ligt. Natuurlijk worden er veel mapping fouten gemaakt waarbij wegen niet met elkaar in verbinding staan terwijl dit wel had gemoeten maar dat moet je niet met een bot oplossen want die weet niet hoe de situatie op de grond is. Daardoor gaat zo’n bot geheid ook dingen stuk maken die toch echt anders bedoeld waren.
Ik vind daarom dat er zeer zorgcvuldig met bots omgegaan moet worden en dat dit dus niet door iedereen gedaan moet worden die een bot kan schrijven.
relaties zijn voor mensen moeilijk te controleren. Zo woon ik tot mijn verbazing al een tijdje in Haarlem, omdat de landuse tag een beetje wijds is gebruikt.
Misschien even twee zaken uit elkaar halen:
Relaties zijn niet altijd compleet: stukjes ontbreken door “wegwerkzaamheden” in OSM. Dat zou je wel graag willen weten. Volgens mij moet een relatie uit 1 stuk bestaan al dan niet gesloten. Lijkt me dat dat verifieerbaar is met een programma. Ik hoop niet dat iemand denkt dat ik voorstel om een automatische repair uit te voeren.
Ik begreep dat Ldp automatisch de lengte van een relatie bepaald en dat onder de distance tag wegschrijft (correct me if I am wrong). Tot nu toe doe ik dat handmatig, wel te doen maar iemand zei terecht: als er een wijziging wordt gemaakt moet je de handeling geheel herhalen. Dus een “bot” die dat doet zou volgens mij wel handig zijn. Dan moet je wel zorgen dat je “hele” relaties hebt, daarom punt 1).
Uiteraard zul je altijd relaties hebben die nog niet of niet meer compleet zijn. Dit kun je inderdaad in een automatische rapportage opnemen. Met mijn voorstellen voor uitgebreidere tagging, is dat volgens mij nog makkelijker, omdat de eindnodes dan ook in de relatie zijn opgenomen, en je dus de eindpunten weet.
Nee en ja.
Nee, ik schrijf geen afstanden weg in relaties, en ik ben er (onder voorbehoud[1]) ook geen voorstander van. Ik was degene die zei dat je het dan wel iedere keer moet bijhouden.
Ja, ik bepaal automatisch afstanden voor rcn-routes (knooppuntroutes)., en die render ik op de openfietskaart.nl. Nu nog alleen op mijn eigen testomgeving, maar binnenkort zal dit ook verschijnen op de publieke openfietskaart.nl server. Deze testomgeving draait bij mij thuis, vandaar dat ik de link hier niet zal noemen, om potentiele overbelasting (of teleurstellingen, als ik bezig ben en het werkt niet) te voorkomen, en om te voorkomen dat de link in zoekmachines verschijnt.
[1] Het voorbehoud is dat het automatisch bepalen en renderen op de kaart niet overal mooie beelden oplevert. Als er een moeilijke geometrie is voor de route, met veel forward/backward role-gebruik, dan gaat het volgens mij nog niet helemaal lekker. Dit is met mijn methode ook niet makkelijk op te lossen. In zulke gevallen kan ik me voorstellen dat een route_length tag, indien aanwezig, voorrang zou kunnen krijgen boven de automatische lengtebepaling.
zoals enige tijd geleden gemeld, heb ik contact gehad met de maker van RelationCheck. Hij heeft nu voor alle Relations in de Nederlandse kaart de “Relations” ge-"Check"t.
Ze zijn hier (http://www.gary68.de/osm/qa/special/nl/relations/nl.zip) te vinden. Het zijn ruim 700 png files die voor iedere relatie in Nederland aangeven hoe de status is, bestaand uit meerdere stukken, delen met forward/backward.
Klopt, dat zijn alleen de relaties waar problemen mee zijn. In de “statistics file” staat het echte aantal:
STATISTICS
number problems 737
number relations 5411
number checked relations 5228
number members 81946
number member ways 62447
number member ways invalid 467
number related nodes 423674
Ik snap nog steeds het gebruik van forward/backward in de relatie niet. Bijv bij deze route 63 naar 97: http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=38271
Die is gefragmenteerd in 3 segmenten. In het middenstuk ligt er aan weerszijden van de Heiligenbergerweg een fietspad (oneway). Moet er dan bij die fietspaden aan beide zijden forward staan? Of de ene richting backward (bij richting 97) en de andere kant op forward?
In de pagina over Route staat het volgende over forward/backward
Kennelijk heeft een route een richting. forward zou betekenen dat je route een éénrichtingsweg volgt in de richting van de route, backward tegen de richting in (weet niet of er bijvoorbeeld rekening gehouden wordt met opposite_lane.