Sterker nog, ik kan nu al dynamisch de lengtes krijgen uit de database, maar de vraag is hoe dit het beste is te renderen. Aangezien een relatie niet verplicht lineair is, je kunt bijvoorbeeld makkelijk een mooie gesloten O-vorm in je relatie maken (denk aan fietspaden aan weerszijden van de weg, met forward/backward roles), zal lengte niet altijd representatief zijn.
Ook een relatie die een stukje mist, wordt nu in de rendering gezien als 2 aparte stukken weg, met elk zijn eigen lengte. Als je als voorbeeld de LF1-route pakt, dan heb je nu allemaal korte stukjes van die route langs de kust, en kun je alleen maar op elk stukje apart de lengte krijgen. Je zult niet de hele 200+ km als waarde krijgen, totdat de hele route ononderbroken in OSM zit.
Andersom: het zichtbaar maken van dit soort dingen kan er ook voor zorgen dat deze dingen juist opgeschoond en gecompleteerd worden.
Ach, zorg nou eerst maar eens dat je een lengte aanduiding op de kaart hebt staan Zeker voor de knooppunt routes moet dit toch te doen zijn. Alle stukken in de relatie bij elkaar optellen en voila, de stukken die niet in de relatie zitten tel je gewoon niet mee.
Voor een LF route is het wat lastiger idd, hebben die gedefinieerde ‘strekken’? Zo ja dan zullen we die moeten mappen en gaan gebruiken, anders zie ik eigenlijk weinig mogelijkheden…
Met een nauwkeurigheid van van 1/10 km zul je zowieso al de meeste verschillen tussen forward en backward plat slaan.
Ik zat inderdaad ook meer aan de knooppunten en de lokale rondjes te denken. Ik denk ook niet dat het bij de LF echt belangrijk is, omdat je het toch niet in 1 rit kunt fietsen.
Afronden zal ik inderdaad op 1 decimaal doen, meer is echt niet nodig.
Ik werk eerst de nog openliggende probleempjes af, want de basislaag van openfietskaart.nl is nu ook gebaseerd op de OSM stylesheet van een jaar geleden, en de praktijk is ondertussen verder. OFK rendert bv niet waterway=riverbank (kijk maar eens tussen Gorinchem en Werkendam), en dat heb ik lokaal al gefixt.
Jij hebt hem al gezien, maar voor de anderen: ik heb afstanden op de kaart, werkend. Of het in moeilijke topologieën ook bruikbaar is, zal de praktijk moeten uitwijzen. Stukken waar met forward/backward wordt gewerkt zijn volgens mij nog niet altijd goed.
We zijn nu met een nieuwe tileserver bezig, en daar wil ik de update van openfietskaart.nl ook neerzetten. Nog een paar dagen geduld, denk ik.
Gezien mijn programmeer skills zal mijn bijdrage voorlopig heel beperkt zijn in deze discussie.
Ik heb wel mijn zorgen over de "kwaliteit"van de relaties. Ik kwam bij het browsen een relatie checker tegen. Eentje die in Perl geschreven is en op een osm.planet file moet draaien. Voor degenen die daar wat aan denken te hebben: http://wiki.openstreetmap.org/wiki/Relation_Check
Als het wat is laat het hier dan even weten.
De ontwikkelaar Gary68, die meer van dit soort check programma’s heeft gemaakt.
Zo te zien wordt het wel wat met automatisch invoeren van de lengte van relaties. Hoop dat dat goed gaat.
Verder het verschil tussen heen en terug weg zou ik niet zorgen over maken. Als je een rondje rijdt is het verschil 2piwegbreedte. dat is typisch voor Nederland 60 meter. Als je dus op 0.1 km nauwkeurig bent, zit het wel goed (tot dat Galileo operationeel is tenminste).
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.
Dat zou voor mij al reden zijn alle routes nog een keer te controleren.
Zeker voor de knooppunt routes moet dit toch te doen zijn. Alle stukken in de relatie bij elkaar optellen en voila, de stukken die niet in de relatie zitten tel je gewoon niet mee.
Kwestie van klemtoooon?