Ik hoopte dat men die informatie in de name zet maar ik geef de strijd op. Blijkbaar wil men absoluut die note houden (en het is nu toch duidelijk dat die info in de note nuttig of zelfs onmisbaar is). Het gevolg is dat de belangrijke info nu mooi verstopt wordt in Potlach en vele gewone mappers die info moeten missen. Ik denk dat die knooppunten dan maar best onderhouden worden door JOSM-gebruikers. Weer 1 gefrustreerde mapper erbij.
Op 29 augustus 2012 19:22 schreef Jo <winfi...@gmail.com> het volgende: > > > Op 29 augustus 2012 12:57 schreef Ben Laenen <benlae...@gmail.com> het > volgende: > >> On Wednesday 29 August 2012 08:54:17 Jan-willem De Bleser wrote: >> > 2012/8/29 Jo <winfi...@gmail.com>: >> > > En om dat te bewerkstelligen ga je dan keer op keer die berekeningen >> > > uitvoeren, terwijl dat net zo goed eenmalig kan gebeuren op het moment >> > > dat die knooppuntnummers effectief wijzigen? Ik blijf het >> > > energieverspilling en tijdverspilling (voor de mapper die Potlatch >> > > gebruikt) vinden. Het spijt me zeer. >> > >> > Er is iets te zeggen voor op voorhand te berekenen - dit is het >> > principe van een index in een relationeel databank. Echter is het dan >> > duidelijk dat deze index een gederiveerd waarde is, en wat precies het >> > aan vast hangt. Dit soort datastructuur kunnen we niet in OSM maken. >> > >> > Zelfs als het een dure berekening was zou ik voorstander zijn van het >> > telkens te berekenen, want het in "note=" stoppen helpt niet wanneer >> > een renderer, router of andere gebruiker-software een naam wil geven >> > aan die route. Echter is dit niet een dure berekening, gezien de wegen >> > in de route op volgorde zijn. >> >> Daar ga je toch niet vanuit mogen gaan hoor. Ik neem aan da Jo veel >> routes op >> volgorde heeft gezet in zijn opkuisproces, maar ik geloof nooit dat alle >> routes mooi geordend zijn. >> >> Trouwens, wat betreft dit allemaal, nog een extra gegeven dat in heel de >> discussie nog niet aan bod is gekomen: variantes en verbindingsroutes, >> oftwel >> de routes die we met state=alternate of state=connection aanduiden. Voor >> zover >> ik weet vind je die niet in Oost- of West-Vlaanderen, maar in Antwerpen >> zijn >> ze vrij talrijk. Deze routes horen ook tot het fietsknooppuntennetwerk, >> maar >> missen in quasi alle gevallen een knooppunt langs één van beide kanten, en >> vaak zelfs is er geen enkel knooppunt op die route. Op die routes ga je >> niet >> veel kunnen berekenen... >> > > Ik heb alle rcn routerelaties in België, zowat de helft in Nederland en > nog een aantal in Duitsland nagekeken Om ze te kunnen nakijken, heb ik ze > ook gesorteerd. Het is alweer een paar maanden geleden dat ik nog eens > alles overlopen heb, maar ik had ergens gehoopt dat er nog anderen > interesse zouden tonen om dit voor hun eigen buurt/provincie te gaan doen... > > Als er een verschillend pad gevolgd wordt van xx naar yy, dan komt het > gedeelte van xx naar yy eerst, gevolgd door het stuk van yy naar xx (met de > resp. forward/backward roles, waarbij ik waar mogelijk de zin van de ways > heb gewijzigd, zodat het grotendeels forward roles zijn), gevolgd door de > rest van de route. Dat is wat het sorteeralgoritme in JOSM tegenwoordig ook > doet. Enkel bij de staarten/tentakels is het arbitrair welk stukje eerst > komt. > > Die variantes en verbindingsroutes, daar heb ik ook m'n tanden wat op > stukgebeten. Dan staat er in note bv > > "73 - 78-80" of "76-80 - Centrum Boortmeerbeek" o.i.d. > > Het wordt al zeer complex om dat nog automatisch te gaan bepalen. In de > rwn-routes zijn er een aantal die "77 - START" o.i.d. heten. Dat kan wel > automatisch aangezien de rwn_ref daar ook START is, als ik me niet vergis. > Maar er zijn wel meerdere nodes in een netwerk met START als rwn_ref... > > Ik blijf erbij dat het gewoon tonen van note de meest voor de hand > liggende oplossing was geweest. En ik hoop dat er niemand op het idee gaat > komen om te opperen dat de note tag overbodig of redundant zou zijn. Dat > was namelijk de indruk die ik op een bepaald moment kreeg. > > Jo > > _______________________________________________ > Talk-be mailing list > Talk-be@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-be > >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
