On 11-8-2010 20:30, ce-test, qualified testing bv - Gert Gremmen wrote:
Misschien kan je de bijdehandjes even laten
wachten op het eind van de discussie ?
Dan heb je geen discussie, maar eenn ja-knikkersmonoloog.
Argumenten voor zijn er genoeg:
- Er staat echt een bord met een naam !
En daarom zit die naam op de netwerkrelatie.
Wat moet je in jouw situatie doen als dat knooppunt in 2 netwerken zit?
Ik sluit niet uit dat dit kan voorkomen.
- We spreken ook over een punt met een knooppunt "naam" ; spreekt de burger
over rcn_ref ?
We spreken ook over "weg". Spreekt de burger over "highway"? De tags
dienen een doel, en dat is een gemeenschappelijke en algemene manier om
een eigenschap van een object vast te leggen, wereldwijd indien nodig.
Dat de key niet overeenkomt met wat in een bepaald land in een bepaalde
taal de echte uitdrukking is, is helemaal niet belangrijk.
- Er is geen reden waarom een knooppunt nog een andere naam heeft, een
knooppunt kan zelfs niet
een naam gemeenschappelijk hebben. Waar dat het geval is is het beter om te
splitsen. Ik ben nu al
5-10 fietsroutes tegengekomen die door iemand onwetend zijn gedeleted of
verplaatst omdat het onduidelijk
is dat er knoopjes inzitten. De blauwe dot in JOSM valt niet erg op. Hoe dat
zit in Putlotch weet ik niet.
http://www.openstreetmap.org/browse/node/42887890
Ja, de place=* name zou op een andere node kunnen, jouw argumenten in
ogenschouw nemende. Er zijn vast nog wel andere situaties te bedenken
dat je *wel* een name=* 'botsing' krijgt.
Denk je dat die onwetendheid opeens minder is als een node een naam
heeft? Welnee, mensen krijgen relaties prima stuk, hoeveel 'hulp' je ook
biedt.
- Onze relatie is ons eigen bedenksel. Bij het maken van de traject relatie en
bij de netwerk relatie
loop je steeds tegen het probleem aan dat je niet kan zien welk vage
knooppunt nummers er nu eigenlijk in zitten.
Je ziet alleen node nummers.
Dat is een editorprobleem, niet van het datamodel. Fix de editor.
Alleen via een omslachtige methode kan je dat zien. Geef je de knooppunten
een naam, dan zie je dat direct
in de relatie editor
Fix de editor. Ik heb trouwens nog geen enkele manier de behoefte gehad
om in de relation editor in 1 oogopslag te zien welke nodes er allemaal
inzitten. Als je een node geselecteerd hebt, en je wilt die toevoegen,
kun je ook snel genoeg zien of die er al in zit.
Je schrijft:
Dit lijkt me duidelijkheid niet echt te bevorderen
Welk argument heb je daarvoor ? Je geeft er nul.
- Naamsverandering van een netwerk. Opname van een netwerk in een ander
netwerk. In jouw geval moet je alle nodes af. Nu hoef je maar in 1
relatie de name te veranderen, cq wat nodes in een andere relatie te hangen.
- Overbodige informatie op de nodes, die prima via de relatie is te
vinden. Een van de redenen dat ik de knooppunten in de netwerkrelatie
zet, hoewel je ze ook indirect via de routerelaties zou kunnen vinden.
Dit is een " niet nodig " (redundant) argumentatie. Wat is er precies tegen
redundantie?
Mijn PC heeft een redundante voeding, weglaten maar ?
*shock!* Heb je geen UPS? Waar is je redundantie voor de
elektriciteitsvoorziening zelf?! :-)
Redundantie verhoogt in dit geval ook de last van de mapper, die op meer
dan 1 plek dezelfde data moet invoeren. Het verhoogt ook de kans op
discrepanties op het moment dat op een van die plekken de informatie
aangepast moet worden, en de andere plek vergeten wordt.
Zoveel wegen en objecten bestaan uit overtollig veel nodes, vallen we over 10
redundante tekens ?
x het aantal knooppunten in een netwerk, en niet elk netwerk heet
kortweg 'Kust'. Het is gewoonweg niet nodig, en jouw hele probleem
draait schijnbaar over hoe het er in -1- editor uitziet.
Neen. tagging schema is bedoeld om te standaardiseren en ONNUTTIGE redundantie
te verminderen.
De name=* ook op de knooppuntnode zetten *is* onnutige redundantie.
Trouwens, jouw voorstel heeft ook nog eens een hybride naam: voorvoegsel
+ netwerknaam + knooppuntnummer. De keuze daarvoor is ook al arbitrair,
en dient alleen maar een enkel doel: de editor foppen.
De knooppunten van een naam voorzien maakt het makkelijker om te editen en is
daarom nuttig.
Als er betere editors zijn kan dat er ook wel weer af.
Ik ben blij dat je hier tot inkeer komt. Fix de editor(s). :)
Denk dat het beter is een geavanceerde zoekfunctie te krijgen, waarbij
je binnen een relatie kunt zoeken.
Zolang die er niet is .....
- Selecteer de relatie in JOSM
- Zoek naar "rcn_ref=10 child selected"
Presto, node 10 is geselecteerd.
--
Lennard
_______________________________________________
Talk-nl mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-nl
