<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014-11-01 1:43 GMT+01:00 Thomas <span dir="ltr"><<a href="mailto:osm@aptum.nl" target="_blank">osm@aptum.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
      Voor wat betreft de relaties tussen de huisnummers en straten
      sluit ik mij deels aan bij Ben: vanuit mijn
      informatica-achtergrond ben ik een groot fan van dit soort
      relaties. Vanuit mijn ervaringen met niet-informatici weet ik
      echter dat dat soort abstracte koppelingen die geen zichtbare
      weerslag hebben en puur een ordening op meta-niveau zijn vaak voor
      ellende zorgen. Ik vind dat soort relaties een zeer elegante
      oplossing, maar tegelijkertijd te abstract voor een brede
      toepassing. <br>
      <br></div></blockquote><div><br></div><div>vergeet niet dat het hier om een geografische databank gaat. Relaties tussen objecten worden ook (in de eerste plaats zelfs) afgeleid uit hun onderlinge positie. Er is geen reden om deze expliciet te maken in een ander object (relatie), zoals bij een relationele databank. Ik dacht tot voor een jaar ook in termen van relaties, maar doordat op de verschillende fora en mailing lists zo dikwijls over dat geografische aspect gehamerd wordt, heb ik mijn mening herzien</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
      Het toevoegen van postcode en gemeente tags op een adres vind ik
      dan weer lastig; waar houdt het op?</div></blockquote><div> </div><div>Je het die enkel nodig voor de paar uitzonderingsgevallen zoals bv die langestraat 14 & 15 die Jo aanhaalt, omdat dat "enclaves" zijn binnen een andere postcode grens. De Engelsen doen het bijna uitsluitend met alles op de node omdat hun postcodes geen zones zijn. </div><div><br></div><div>Ik heb vorig jaar al eens een berekening gemaakt hoeveel ruimte een associatedStreet relatie inneemt versus een expliciete straatnaam tag. Je moest al een lange naam hebben wou de relatie minder getransfereerde bytes inhouden voor JOSM.</div><div><br></div><div>Geocoders en navigatie programma's herstructuren de data toch nog volledig, dus je weet niet wat daarvoor de interessantse structuur is. Ze kappen bijvoorbeeld toch alle straten verder in stukken op de kruispunten. Dus plaats besparen door een straat niet in stukken te kappen maakt voor hen ook niet uit.</div><div><br></div><div>Dus voor mij:</div><div><br></div><div>- alle gemeente grenzen en postcodes in boundary relaties (en ja daar moeten we dan maar werk van maken)</div><div>- enkel straat en nummer op node</div><div>- bij uitzonderingsgevallen city & postcode op node</div><div><br></div><div>eenvoudiger kan het niet :-)</div><div><br></div><div>mvg</div><div><br></div><div>m</div></div><br></div></div>