<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/10/16 Marc Gemis <span dir="ltr"><<a href="mailto:marc.gemis@gmail.com" target="_blank">marc.gemis@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>1) Zouden we misschien kunnen afstappen van de regel om huisnummers op de gebouwen te plaatsen ? Zeker in steden waar al grote blokken getekend zijn, is het een serieuze job om die allemaal te verbeteren (want op Bing gebaseerd) en dan nog eens te splitsen. En wat is de toegevoegde waarde ? Je zal bovendien nog dikwijls naar de Agiv website moeten gaan kijken om te weten welke bijgebouwen nu bij welk huisnummer hoor.</div>


<div>Mensen die toch willen splitsen kunnen dat nog altijd doen. Het is een beetje zoals de kerken die nu soms met 1 enkel punt zijn aangeduid. Later kan iemand nog altijd het gebouw tekenen.</div></blockquote><div><br></div>
<div>Normaal zijn die adressen uit CRAB, als ze op een gebouw staan als, ook in de csv-files even accuraat als op de AGIV-webiste. Misschien zit er nog een fout in mijn script.<br><br>Ik ben wel voorstander van het plaatsen van adressen op gebouwen omdat dat echt een meerwaarde is en het duidelijk is welk gebouw bij welk adres hoort. Natuurlijk weet ik ook dat dit niet overal kan. Als je de discussie over de import in new york hebt gevolgd zijn daar dezelfde discussies aan de gang.<br>
<br></div><div>De bottom-line voor mij: Ik wacht liever langer tot alle adressen erin zitten dan voor een andere import-manier te gaan omdat de manier van werken sneller is. De adressen zouden er toch alleen maar voor geocoding in zitten en daarvoor is de AGIV dataset toch al beschikbaar.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>2) De associatedStreet relaties: laat die vallen. Dat is voor velen te complex. Zeker in de gevallen waar de straat ook de gemeentegrens is, of als er al een relatie bestaat. Wie wil kan ze gemakkelijk zelf creëren. Met "find" in JOSM kan je alles dat in 1 relatie hoort in 2 keer vinden. Nog eens kijken of het niet mogelijk is met 1 find (als er een OR bestaat)</div>
</blockquote><div><br></div><div>Hier ben ik het eigenlijk wel grotendeels mee eens. De tool van de fransen is echter het enige dat ik op deze moment heb. Ik weet niet hoeveel werk het zou zijn om die relatie te laten vallen.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br></div><div>Dus wat houden we over: nodes met alle adres informatie (dus inclusief addr:street, addr:city en addr:postcode) die misschien een beetje verschoven moeten worden, wat duplicaten hier en daar verwijderen en dan terug opladen naar OSM. Dit is eenvoudig en gaat snel vooruit. Alle adres informatie is er dan ook als dit gebeurd is. Nadeel is dat nominatim alle adres informatie (buiten het huisnummer) niet bekijkt en de node bij de dichtsbij zijnde straat rekent. Dit zou bij hoekhuizen een probleem kunnen zijn, maar de "fout" ligt hier bij de afweging van nominatim om de index kleiner te houden.</div>


<div></div></blockquote></div><br></div><div class="gmail_extra">Dat is in mijn ogen ook een nominatim probleem en uiteindelijk geen probleem voor 99% van de adressen die we zouden mappen.<br></div><div class="gmail_extra">
<br clear="all"><div><div dir="ltr">Met vriendelijke groeten,<br>Best regards,<br><br>Ben Abelshausen<br><br></div></div>
</div></div>