[OSM-talk-nl] FRN Stadsregio Arnhem - Nijmegen

[Jo]

Hallo Frank,

Op 20 november 2011 05:23 heeft Frankl2009 <frankl2009 at xs4all.nl> het
volgende geschreven:
>
>> Wat bedoel je met de superrelatie? De networkrelatie?
>
> yup.
>
> Even een zijdelings discussie buiten talk-nl om, Jo,
> neem het aub niet als een verwijt:

Ik neem het niet als een verwijt. Discussie komt beter laat dan nooit,
maar ik zie niet in waarom we dit buiten de lijst om moeten doen, dus
zend ik het toch weer daarheen. Hopelijk is dat geen probleem.

>
> De Wiki
> Ik zie dat je nogal wat hebt veranderd in Lennard's pagina Advanced Cycle
> Tagging.

Ik probeer om de 'ground rules' vast te leggen en zie die pagina als
een werkdocument. Wat mij betreft, is het perfect dat daar nu reactie
op komt. (Liefst voordat ik aan een vertaling begin). Uiteindelijk
moet daar precies op worden uitgelegd, hoe netwerken van
knooppuntenroutes moeten worden gecodeerd. Toen ik begon, heb ik daar
niets gevonden over tentakels (aan begin of einde van gesplitste
knooppunten) of hoe roles te gebruiken, als de heenrichting
(laag->hoog) afwijkt van de terugrichting (hoog->laag). Als het even
kan, wil ik dus zaken verduidelijken. Als ik daar niet in geslaagd
ben, heb ik gefaald. Het is dus zeker goed dat er opmerkingen komen.
Ik laat ze dan even bezinken en dan val ik die pagina opnieuw aan. Al
zal het misschien nodig zijn om wat voorbeelden te vermelden of om er
wat illustraties bij beginnen te zetten omwille van de complexiteit.

>
> Nu lijkt het alsof we geen knooppunten moeten opnemen in een routerelatie,

inderdaad

> "There is no need to add the junction nodes to this relation. They are part
> of the ways, so inherently already part of it. This allows for a more
> controlled way of downloading the hierarchy (collection/network/route)."
> en dat was nu net niet wat hij bedoelde met zijn redactie.
> ''Current thinking makes that these nodes are not truly necessary, since
> they can be infered through the member ways. Don't go out of your way to add
> them.''
> Toen jullie daarover correspondeerde op talk-nl, heb ik de pagina opnieuw
> bekeken, en kon leven met zijn redactie (hij liet het nog open).

Hij liet het open en nam daardoor dus eigenlijk nog steeds geen
standpunt in. Ik heb het een tijd zo gelaten, totdat ik me serieus met
die pagina ben beginnen bezighouden. De twee keer dat ik die pagina
grondig heb aangepast, heb ik dat ook gemeld op de mailing list. Het
probleem is dat ik niet eens helemaal zeker ben dat dat wel de juiste
pagina is om als basispagina te dienen, aangezien er ook nog
specifieke pagina's bestaan voor België en Nederland apart. Ik ben dus
aan het trachten om het op deze pagina allemaal correct te
beschrijven, dan te vertalen en dan de specifieke pagina's te laten
doorverwijzen, maar ik ben er nog niet klaar mee.

> Hij weet uiteraard dat er nogal wat mensen zijn die juist de moeite genomen
> hebben en nog nemen om dat wel te doen (het stond immers in de wiki al een
> paar jaar).

Ik weet dat het mensen moeite heeft gekost om die toe te voegen. Het
resultaat is dat er zo'n 45% van de routes is, die wel knooppunten
bevatten en om en bij de 55% die ze niet hebben. Ik ben aan het
proberen om alles op dezelfde noemer te zetten. Als ik daarover iets
zeg op de mailing list, krijg ik bijzonder weinig commentaar. Dus had
ik enkel, wat als een groen licht beschouwde, van Lennard.
Ik vergelijk het zo'n beetje met de licentiewijziging. Er zijn mensen
die de moeite hebben genomen om tags zoals name e.d. toe te voegen aan
objecten. Nu zijn ze niet bereikbaar of ze zeggen neen tegen de
wijziging, met als gevolg dat hun bijdrage moet worden verwijderd. Dat
doe ik dan met veel tegenzin, maar ik kan het object niet vervangen
door een object dat na 1 april zal blijven bestaan met die name erop.
In ieder geval kost het mij ook enige moeite en tijd om die
knooppunten uit de routes te verwijderen. Ik doe echter niets, wat ik
niet automatisch terug zou kunnen herstellen, als dat de consensus
is/wordt.

>
> Ik begrijp je argument dat ze niet strict nodig zijn ("maken deel uit van de
> wegen") maar niet waarom het een meer "controlled way of downloading the
> hierarchy" helpt/hindert. Je hoeft toch helemaal niets te doen met die
> knooppunten?

Of is er een technisch probleem in JOSM als je dat doet?

Als je in JOSM een relatie afhaalt, dan worden de members niet meteen
mee afgehaald. Als je een knooppunt afhaalt, dan worden de parents wel
meteen afgehaald. Als je nu dus een networkrelatie afhaalt, heb je wel
alle knooppunten, maar nog niet alle routes. Die haal je dan af in de
volgende stap. Maar je kan je beperken tot de routes die je nodig had.
Server wordt niet onnodig belast.

Als de knooppunten deel uitmaken van de routes, dan komen alle routes
meteen ook mee, op het moment dat de knooppunten worden opgehaald, als
ik me niet vergis.

Je kan dit ook als een voordeel beschouwen, aangezien er dan minder
stappen nodig zijn om een hele collectie netwerken af te halen...
>
> Ik heb niet gemerkt dat je verder aanpassingen expliciet op talk-nl had
> besproken (anders was ik weer gaan kijken naar de wiki en had ik eerder aan
> de bel getrokken over de knooppunten in de routerelaties).Er is ook geen
> discussie geweest op een Talk pagina. Maar de meeste van ons gaan niet
> ineens kijken wat de stand van zaken is op de wiki als we al weten hoe we
> moeten taggen/relaties leggen. Dat levert last op.

Zoals gezegd, ik ben aan het trachten om tot 1 enkele manier te komen
om die routes en netwerken in kaart te brengen. Als er wordt beslist
dat de knooppunten toch deel moeten uitmaken van de routes, dan leg ik
me daarbij neer en ik zorg ervoor dat die knooppunten aan alle routes
worden toegevoegd. Ik vind consistentie belangrijk, niet de precieze
manier waarop de dingen gedaan worden.
>
> Verder inhoudelijk, denk ik dat de opmerking over "roundabouts" en
> forward/backward roles is onjuist (als ik het goed begrijp), d.w.z. als je
> bij een rotonde een apart liggend fietspad hebt (meestal ook éénrichting) en
> alleen bij de feitelijke locatie van een infopaneel een rcn_ref zet.

Dat gaat over rotondes (gewoonlijk in het midden van een route), die
niet gesplitst is en die geen apart fietspad heeft waar de route
overheen gaat. Dat soort rotondes heeft geen role nodig, aangezien ze
dan door mijn script enkel aan de vanLaagNaarHoogLijst wordt
toegevoegd (zie uitvoerige beschrijving werking script van vannacht)

Dan zal
> je als fietser de rotonde om moeten fietsen om bij een paneel te komen.
> Hetzelfde geldt bij ingewikkelde kruisingen met vrijliggende fietspaden
> tenzij ze voor tweerichting verkeer zijn uitgevoerd. Omdat er meerdere
> routes van verschillende wegen komen en gaan, is het altijd puzzelen om het
> goed te krijgen. Eénrichting fietspaden leveren altijd forward (of bij grote
> uitzondering backward) rollen op in relaties, dus ook bij rotondes.

Bij vrijliggende fietspaden ben ik het volledig met je eens.

>
> Ik begrijp ook niet de alinea's beginnend: "Sometimes the routes branch
> ...", Ik denk dat dit dezelfde discussie is over het gebruik van
> forward/backward. Als het gaat om eenrichting fietspaden aan wederzijds van
> een weg, en de fietspad is (laten we hopen) uitgevoerd met een tekenrichting
> gelijk aan de feitelijke eenrichting (dus niet getekend in omgekeerde
> richting en getagd oneway=-1), dan is het altijd een forward role.

Als ik dat soort aberraties tegenkom, draai ik de zin van de way om.
Je hebt dus gelijk als je zegt dat het overwegend forward roles zullen
zijn. Heb ik dat niet zo vermeld op die pagina? Of heb ik dat zo
onduidelijk gesteld?

>Zoals het
> nu gesteld is in deze alinea's zal de verwarring zeer groot zijn voor de
> eenvoudige mapper zoals ik. (Ik ga toch geen Python script in JOSM laten
> lopen).  Of je gelijk hebt, weet ik niet; maar dit is niet zoals Lennard/ldp
> het steeds heeft uitgelegt. Hoe de routers hiermee omgaan (of niet) is ook
> zeer de vraag.

Ik ben helemaal in het begin even in de war geweest over die
forward/backward roles. Maar dat is ondertussen overal weer
rechtgezet. Ik had de vraag gesteld op talk-be. Niemand reageerde, ook
Lennard niet en wat ik in de 2 weken daarna deed, was allemaal fout.
Maar nu dus niet meer.

Zoals het nu is, is de enige manier om ervoor te zorgen dat de delen
van de routes, die niet hetzelfde verlopen van laag naar hoog, als van
hoog naar laag gedetecteerd kunnen worden, als ze in een bepaalde
VOLGORDE in de relatie zitten (als je een route waarvan de wegen de
correcte rollen hebben, gaat sorteren in JOSM, dan is het resultaat
hetzelfde als wat ik daar tracht te beschrijven).

Als de ordening/volgorde van de ways in de routerelatie niet klopt,
dan kan mijn script daar niets mee. De data moet dus enigszins worden
'voorgekauwd'. Ik noem dat efficiënter, misschien zou ik wel iets
uiterst intelligent kunnen programmeren in dat script, zodat het die
sortering van de leden steeds opnieuw uitvoert, maar dat verbruikt,
m.i. onnodig energie. Dus verwacht ik dat de wegen in routerelaties
gesorteerd zijn, voordat mijn script daarmee aan de slag gaat.
Coïncidentally is dit ook voor gewone stervelingen gemakkelijker om de
continuïteit van een route op het zicht te bepalen (in JOSM dan toch).

>
> Tot slot: Ik begrijp je frustratie over de reactie die je kreeg van Richard
> F. (Potlatch). Maar ik denk niet dat het stukje over Potlatch helpt.

Wat Potlatch betreft, ik heb een verwijzing gemaakt naar die
wikipagina op het tracticket waar de vraag voor een fallback van name
naar note werd gesteld. Ik heb hen dus op de hoogte gesteld van het
feit dat ik, zeer tegen mijn zin, Potlatch op die pagina in een slecht
daglicht heb gesteld.
Eigenaardig genoeg wordt ik dan beschuldigd van chantage. Ik zou het
eerder 'klokkenluider' o.i.d. noemen. Iemand die inzit met de noden
van de gebruikers van de tool die zij aanbieden.

http://trac.openstreetmap.org/ticket/4017

Maar goed, ik ben ne rare en ben bang dat ik dat ook altijd wel zal
blijven, zeker. Ik zou het niet durven voorstellen, maar wellicht
helpt het als meerdere mensen daar zouden bevestigen dat 'note' is
here to stay and is the way it's always been done for tens of
thousands of route relations. (begin de routerelaties voor wandel- en
ruiterknooppunten er ook maar bij te tellen)
Want nu lijkt het erop dat ze dat niet willen implementeren, omdat ze
er van uit gaan dat de een of andere gek dat op een wikipagina heeft
geschreven. Maar dat is één ding dat toch wel zeer breed aanvaard is.