On 03/03/2013 06:04 PM, Gertjan Idema wrote: > Eén puntje wil ik wel in overweging geven: Als iemand netjes de > officiële naam opgeeft in bijvoorbeeld nominatum, dan zou het wel zo > prettig zijn als de bijbehorende plaats dan ook wordt gevonden.
Op het moment word zelfs zonder het gebruik van de official_name tag voor beide namen vrijwel dezelfde resultaten getoont. Dus daar hoeven we het niet voor te doen. On 03/03/2013 06:04 PM, Gertjan Idema wrote: > On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: >> Huidige status: >> >> done: 2000, TODO: 484, Total: 2484 (complete: 80.5152979066023%) > > Als ik het goed heb, zouden het er 2500 moeten zijn. (2505 > woonplaatscodes als je de 'dubbelen' mee telt). Klopt. Ik was Flevoland vergeten in het overzicht. Zuid Holland heb ik vandaag afgemaakt, en daarmee is de huidige status: done: 2152, TODO: 349, Total: 2501 (complete: 86.0455817672931%) On 03/03/2013 06:04 PM, Gertjan Idema wrote: > On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: >> Maar hiermee heb je niet de waterway=river wegen die vaak over grenzen >> getrokken zijn, en de verschillende highways, buildings e.d. Als je alle >> mogelijkheden wilt afvangen moet je alle data binnen de boundingbox >> ophalen en dat is al snel teveel voor een grote stad laat staan een hele >> gemeente of provincie. > > Als de rivier de officiële grens is, betwijfel ik of je grens en de > rivier moet loskoppelen. Valt wat voor te zeggen. Maar het maakt het editten van boundaries buiten de volledige dataset om wel nodeloos meer werk. Idealiter leven de boundaries in hun eigen layer, omdat ze niet interacteren met de andere data. Ze hoeven niet gekoppeld te zijn voor routing of iets dergelijks. Hekken en degelijke barriers kunnen overlap hebben met boundaries en zouden van dezelfde ways en/of nodes gebruik kunnen maken als een hekwerk is geplaatst om de grens op locatie aan te duiden. Maar kunnen net zo goed los van elkaar staan. In mijn ogen is een administratieve grens een virtuele feature die per definitie losstaat van de features die op de grond kunnen bestaan. Zodoende dient de logische scheiding tussen de features behouden te worden door diens nodes en ways niet te combineren. Wanneer een rivier of andere niet-virtuele feature gebruikt word ter bepaling van een grens dient de logisch scheiding gerespecteerd te worden. Zo kunnen de ways over elkaar getekend worden maar geen nodes te sharen, of mijn voorkeur, teken de waterway en boundary vlak naast elkaar. On 03/03/2013 06:04 PM, Gertjan Idema wrote: > On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: >> On 02/27/2013 09:34 PM, Gertjan Idema wrote: >>> On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote: >>>>> Andere klussen: >>>>> Het gebruik van type=boundary/type=multipolygon nog niet consequent. >>>>> Volgens de Nederlandse conventie gebruiken we type=multipolygon. Op de >>>>> internationale site staat echter dat type=multipolygon verouderd is. Dat >>>>> is nogal verwarrend. Huidige status: multipolygon=2173x, boundary=327x >>>> >>>> Een van de JOSM ontwikkelaars pushed de standaardisatie naar >>>> type=boundary. En als je op basis van de wiki of taginfo beslist hoe te >>>> taggen zal type=boundary altijd de voorkeur hebben. >>> >>> Ik kan op zich leven met 'type=boundary' als dit overal behalve in Nederland >>> en Duitsland de standaard is. Dan is het wel zaak om de Nederlandse >>> documentatie >>> hier op aan te passen. Eerst maar eens uitzoeken wat destijds de argumenten >>> voor >>> type=multipolygon waren. >> >> Het enige nadeel aan type=boundary is wat mij betreft dat hier standaard >> een warning voor getoond word in OSMI. Maar omdat deze super eenvoudig >> uitschakelen is, het dat redelijk een non-argument. > > Als type=boundary de officiële standaard is, is dat in mijn ogen een bug > in OSMI die binnenkort wel verleden tijd zal zijn. Dat zou mooi zijn, maar ik weet het nog niet zo zeker. Het belangrijkste is dat wij documenteren welk type we gebruiken en waarom, en hoe dat afwijkt van bepaalde documentatie, QA tools, e.d. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) _______________________________________________ Talk-nl mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-nl
