<..wolkjes aan nodes in gebouwen die nergens op slaan...> Ze slaan uiteraard wel ergens op, want ze bevatten cruciale info: te weten een adres. En ook nog eens binnen het betreffende pand. Bij het vaststellen hoe de BAG import zou verlopen is de nodige discussie geweest met de Data Working Group. Een randvoorwaarde van de DWG is dat het voor beginners makkelijk moet zijn om met de adressen te werken, ook met Potlatch (1 / 2) en iD.
Wat voldoet dan precies aan die randvoorwaarde? - De huidige methodiek sowieso (die is door de keuring van de DWG heen gekomen). - Interpolation? Mijn persoonlijke ervaring is dat beginnende mappers rustig losse POI's aanmaken, terwijl ze dat eigenlijk op de geïnterpoleerde lijn hadden moeten doen. Dit is dus voor beginners niet makkelijk genoeg. - Een scheiding met komma's, puntkomma's of een bereik? Zolang het aantal adressen niet groot is, is het nog te overzien. Ik heb diverse appartementen geïmporteerd met tientallen adressen. Dat is dan niet eenvoudig voor een beginner om te splitsen als één van de nodes een POI moet worden Voorts hebben we ook nog het probleem dat we in 2D werken. Bovendien is de vraag waar de adressen horen. Er zijn wat mogelijkheden: de ingang van het appartementencomplex, de deur van het appartement of op de outline van het apartement. Kortom: er is nog geen goede oplossing beschikbaar voor het taggen van adressen op apartementen. De huidige wolkjes zijn een compromis dat goed werkt totdat een definitieve oplossing beschikbaar is. Op http://wiki.openstreetmap.org/wiki/Addresses en Proposed_Features/Multiple_addresses<http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses> staat meer informatie over eerste oplossingsrichtingen voor het taggen van adressen op apartementen. Het lijkt me prima dat we deze discussie op OSM-NL voeren, maar het is nog handiger als mappers buiten Nederland mee kunnen gaan denken. Dat kan via https://lists.openstreetmap.org/listinfo/tagging Ik ben in ieder geval geen voorstander van het hermappen van de huidige wolkjes conform een bepaalde taggingmethode als die betreffende taggingmethode nog niet goed is uitgekristalliseerd. Cheers, Johan Op 4 mei 2014 21:55 schreef webmind <webm...@puscii.nl>: > On 04/05/14 21:40, Harry van der Wolf wrote: > > > > > > > > Op 4 mei 2014 20:55 schreef Sebastiaan Couwenberg <sebas...@xs4all.nl > > <mailto:sebas...@xs4all.nl>>: > > > > > > > > Het samen voegen van adres nodes in een node m.b.v. interpolation is > dus > > niet aan te raden. > > > > Mvg, > > > > Bas > > > > > > Dit is correct. Adres interpolatie moet op tenminste 2 nodes > > (begin-eind) of meerdere als je bijvoorbeeld een bochtige weg hebt. > > Het is niet correct op een enkele adres node. Eventueel op een building > > (flat) kan het wel, maar daar is het beter om de "addr:flats=" key te > > gebruiken omdat die veel meer mogelijkheden biedt. > > Dat is hier wellicht gepast, vind Nominatim de tussenliggende > huisnummers dan (bv nummer 3 bij addr:flats=1-20)? En kan je dan > aangeven als een flat alleen de even nummers heeft? > > > Terugdraaien van adressen lijkt mij hier niet een juiste stap. > > Behouden van wolkjes aan nodes in gebouwen die nergens op slaan lijkt > mij ook niet wenselijk. Je kan ze mappen op de correcte locatie binnen > het gebouw, mits je die info hebt. Zo niet is het denk ik het slimst om > de voordeur te gebruiken of een in iedergeval een enkele node. > > -- > GPG Key: https://u2m.nl/data/webmind.asc > GPG Fingerprint: 0506 976E 2346 53B4 A628 EC33 E23D 16EE FCF1 54AE > u2m.nl SHA1: B1:E6:D0:01:7E:4B:68:7C:B0:35:EB:C8:52:85:59:7E:D4:E3:1F:AE > Puscii SHA1: 01:CF:FB:9D:1F:E1:D9:13:60:19:E3:25:60:E4:F6:05:8C:CB:2C:A3 > > _______________________________________________ > Talk-nl mailing list > Talk-nl@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-nl >
_______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
