Lennard, Dank voor je duidelijke uitleg. Even een paar opmerkingen/vragen:
> network=rcn is om technische redenen nodig op de routerelatie. Het > proces om de osm db te importeren in pgsql, osm2pgsql dus, heeft deze > nodig om de routerelatie te kunnen verwerken. De osm db is toch een 'normale' relationele database? In dat geval zou ik verwachten dat het mogelijk is de import aan te passen aan het veranderde datamodel, of heb ik dat mis? In dat geval zou de network tag van de bovenliggende netwerk relatie gehaald kunnen worden, evenals de route en type tags. Ik kan me wel voorstellen, dat je om 'backward compatible' te willen zijn de huidige tags laat bestaan. Je ziet hier en daar wel eens verwijzing naar verouderde (deprecated) tags, keepright.at verwijst er naar: 'This way uses deprecated tag landuse=wood. Please use landuse=forest instead!' Bovendien moet het mogelijk zijn een bot te schrijven die dit aanpast. Voor het koppelen van netwerken, in de provincie Friesland heb je 5 netwerken, te weten zuidwest, zuidoost, midden, noordwest en noordoost. Tussen deze netwerken liggen in totaal zo'n 50 routes. Dat zijn er toch voldoende om een 'mooie' oplossing voor te bedenken lijkt me. We hebben dat nu opgelost door een name tag te geven die de koppeling beschrijft: 'FRN Zuidwest-Midden Friesland' bijvoorbeeld. Routes tussen netwerken horen eigenlijk bij geen van beide netwerken. Is het een idee om een link relatie in het leven te roepen die deze verbindingen beschrijft? De link relatie wordt dan gebruikt op de route onderdelen, ways en nodes. De link relatie bevat 2 netwerk relaties, meer lijkt me niet nodig. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Lennard Sent: woensdag 4 februari 2009 0:02 To: OpenStreetMap NL discussion list Subject: Re: [OSM-talk-nl] Fietsroutes Incrorrect getagged Gert Gremmen wrote: > wat is de meerwaarde van het opnemen van de nodes in de relatie > Ik heb dat tot nu toe nooit gedaan, Het heeft ook niet altijd en/of even duidelijk in de wiki gestaan. Het voordeel, in mijn ogen, is dat je zo makkelijk kunt zien of een route compleet is. Als ik nu op een knooppunt aankom, en ik kan daarvandaan 2 kanten op, kan ik er fysiek maar 1 volgen. Dan maak ik alvast wel een route aan voor de andere mogelijkheid, en zet het eerste stuk straat dat ik al kon vaststellen er al in. Zo weet ik, maar ook ieder ander, dat daar nog een mogelijkheid is, die nog niet is uitgewerkt. Ben Laenen wrote: > Vraag is natuurlijk of het niet even makkelijk te zien is als de > uiteindes van die routes een node hebben met een rcn_ref... En horen de > knooppunten ook misschien niet eerder thuis in de overkoepelende > netwerk-relatie? Je hebt gelijk dat je het ook zou kunnen zien aan nodes in member ways, met rcn_ref gezet. Dan moet je echter wel 1 niveau dieper gaan kijken. En de knooppunten staan ook gedefinieerd op de netwerkrelatie: (C) Network tagging [...] This relation holds: [...] All numbered junctions (A) of this cycle node network. Do not add the junctions of the opposite end of connecting routes, as those are in another network. Taede @ orange wrote: > Dan nog iets over het voorstel van Ldp: de route relatie kent (ook in de huidige situatie) meer tags die dubbel zijn. In het voorstel wordt de naam tag naar een overkoepelend hoger niveau getild, maar daar horen ook 2 andere tags: de network=rcn, en route=bicycle kunnen ook een level hoger eenmalig vastgelegd worden, met als type=network. Ze zijn dan niet meer nodig op de route relatie. network=rcn is om technische redenen nodig op de routerelatie. Het proces om de osm db te importeren in pgsql, osm2pgsql dus, heeft deze nodig om de routerelatie te kunnen verwerken. Ook wilde ik zo weinig mogelijk slopen van de huidige tagging. Als je deze tags als vanouds blijft opnemen op de routerelatie, dan kunnen huidige renderers en andere gebruikers van de db, die geen weet hebben van de voorgestelde netwerkrelatie, blijven werken. > Ik zou het dan wel heel erg prettig vinden als het in potlatch mogelijk wordt om relaties binnen relaties toe te voegen. Dat is inderdaad nog een klein gemis in de editors. In JOSM kan het wel, maar daar is het ook niet evident, en moet je het trucje een keer doorhebben. Merkaartor ken ik niet goed genoeg. > Het verhaal over de verbinding tussen netwerken kan ik (nog) niet zoveel mee, misschien dat dit met wat voorbeelden kan worden verduidelijkt? De knooppuntennetwerken zijn op zich redelijk op zichzelf staand, in de zin dat ze ingericht zijn door een bepaalde organisatie, meestal binnen een regiofunctie. Alleen, dat idee hebben meer organisaties, dus heb je ook meer knooppuntennetwerken. :) Deze liggen dus regelmatig tegen elkaar aan, en dan zijn er ook routes uitgezet die knooppunten uit 2 verschillende netwerken met elkaar verbinden. Daar gaat het hele verhaal van state=connection (routerelatie) en role=connection (netwerkrelatie) over. Als je bijvoorbeeld een kaart zou willen printen van alleen 1 netwerk, zou je in principe dan alle verbindende routes eruit kunnen filteren. Dit voorstel is ontstaan uit mijn eigen ervaringen met het taggen van deze netwerken in mijn buurt. Wel grensoverschrijdend, maar zeker niet met enkele exoten, zoals Ben Laenen die mij liet kennen. Die heb ik later dan ook verwerkt in het voorstel. Verder is dit voorstel open ter discussie, uiteraard. Omdat dit een redelijk unieke NL/B situatie is, heb ik het nog niet verder verspreid of bekend gemaakt. -- Lennard _______________________________________________ Talk-nl mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-nl _______________________________________________ Talk-nl mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-nl
