Data buiten de grenzen van de Benelux

Willem1 · 2010-01-06T17:44:02.000Z

Het viel mij op dat er opeens allerlei brokken data van buiten de Benelux op de Nederlandse tileserver verschijnen. Hoe komt dat en is dit de bedoeling? Zie bijvoorbeeld een stuk van het Roergebied (http://tile.openstreetmap.nl/?zoom=14&lat=51.43851&lon=7.01699&layers=B000000FF).

Ldp · 2010-01-06T21:06:33.000Z

Dat komt omdat we continu updates (‘diffs’) inladen, en die zijn om technische redenen niet te beperken tot alleen de Benelux. Vroeger viel het niet op, omdat we toen elke nacht alle data opnieuw inlaadden, maar dat doen we nu niet meer.

Als we om een andere reden een keer een volledige herimport doen, dan vallen deze extra stukjes weer weg. Verder zou ik me er niet teveel aan storen, al staat het misschien wel raar op de kaart.

greencaps · 2010-01-07T07:46:38.000Z

Kun je aub uitleggen wat die technische redenen zijn?

Als je bij een volledige herimport wel de data kunt beperken tot de Benelux waarom dan niet bij diff data?

Het ziet er inderdaad niet mooi uit. Eigenlijk best storend.

rullzer · 2010-01-07T08:25:53.000Z

Omdat bij een initiele import we de planet file pakken. Hier kunnen we een polygoon uit knippen en die dan in de database laden. Echter het toepassen van diffjes kan niet met een poly worden beperkt enkel met een bounding box. En als je een bounding box om de hele benelux zet dan pak je een stuk Duitsland en Frankrijk mee…

greencaps · 2010-01-07T08:36:57.000Z

Dan zou ik de technische reden wel willen kennen waarom je mbv een polygoon wel een stuk uit een osm file kunt knippen en niet uit een diff osc file.

rullzer · 2010-01-07T08:47:57.000Z

Iemand moet het gewoon code inderdaad. Dus leef je uit

greencaps · 2010-01-07T09:03:33.000Z

Je zou dus een oscsplitter wel in willen zetten hier. Voor welk OS heb je een nodig?

Ldp · 2010-01-07T13:18:27.000Z

Er zit niet genoeg informatie in een .osc om deze te kunnen verknippen. Bedenk ook wat er zou gebeuren als je wel knipt, en iemand verplaatst een node buiten het dekkingsgebied. Dit feit zou dan uit de .osc geknipt worden, waardoor de node in onze db niet aangeraakt wordt en op zijn oude plek blijft staan.

Kortom, de .osc zelf kan niet geknipt worden, maar na het verwerken van een object uit de diff zou je wel kunnen kijken of je buiten de polygon terecht bent gekomen. De osm2pgsql tool die we gebruiken, kent echter alleen de mogelijkheid van een bbox. De enige plek waar het gefixt kan worden, is dus in osm2pgsql, door de ontwikkelaars te vragen om net als osmosis een willekeurige polygon file te accepteren om op te knippen.

De enige manier om het nu weer goed te krijgen is afstappen van de specifieke polygon om de Benelux, en weer terug te gaan naar een rechthoekige bbox. Dat heeft weer andere nadelen, zoals een fors grotere database en dito verwerkingstijd.

greencaps · 2010-01-07T13:21:31.000Z

Heb mijn osmsplitter nu aangepast zodat ie ook osc files kan doen. Dat werkt allemaal wel. Maar ook niet. Het grote verschil met osm files is dat er way’s in voorkomen waarvan de nodes niet in de file vermeld zijn. Die ways zijn dan niet localiseerbaar tot de benelux. Hetzelfde geldt voor relation’s. In een planet.osm file is wel alles localiseerbaar omdat die alle data bevat.

Heb hem losgelaten op 20100105-20100106.osc ( 579.833 kB). Omdat ik geen Benelux polygoon had en er ook niet een aan openstreetmap kon onttrekken ( …dus niemand heeft ooit een Benelux relatie aangemaakt…) heb ik aparte polygonen voor nederland, belgië en luxemburg genomen. Om er zeker van te zijn dat er inderdaad onlocaliseerbare ways en relatins waren ook nog een polygoon voor de hele wereld toegevoegd. Dan kunnen in iedergeval alle nodes gelocaliseerd worden en als er dan ways en relations over blijven dan klopt de bewering echt.

Hier een deel van de reportfile:
OsmSplitManager:
3115941 nodes
0 out of all areas nodes

147026 ways
128490 ways localised
2 ways localised for more areas
18536 ways not localised
128492 nodeid’s (from a way) found
1712818 nodeid’s (from a way) not found

2009 relations
983 relations localised
0 relations localised for more areas
1026 relations not localised
408 member relations
8 member relations localised
0 member relations localised for more areas
400 member relations not localised
149742 member ways
851 member ways localised
0 member ways localised for more areas
148891 member ways not localised
8027 member nodes
124 member nodes localised
0 member nodes localised for more areas
7903 member nodes not localised

belgium
3233 nodeid’s added
636 wayid’s added
4 relationid’s added
20100105-20100106.osc.oscsplit.belgium.osm

luxemburg
116 nodeid’s added
11 wayid’s added
0 relationid’s added
20100105-20100106.osc.oscsplit.luxemburg.osm

nederland
187051 nodeid’s added
22987 wayid’s added
110 relationid’s added
20100105-20100106.osc.oscsplit.nederland.osm

world
2925541 nodeid’s added
104858 wayid’s added
869 relationid’s added
20100105-20100106.osc.oscsplit.world.osm

18536 ways not localised
20100105-20100106.osc.oscsplit…rest.waysnotlocalised.osm

1026 relations not localised
20100105-20100106.osc.oscsplit…rest.relationsnotlocalised.osm

osmsplit
input from stdin
5983736 lines read

Ja en hoe nu verder. Als ik het goed wil doen dan moeten de onlocaliseerbare ways en relaties in een tweede pass via de API gelocaliseerd worden. Dat is wel te doen natuurlijk maar dat moet dan nog geprogrammeerd worden.

Maar eigenlijk zit ik met hetzelfde probleem als wanneer je met een bounding box werkt. Hoe worden dan nu de ways en relations al dan niet meegenomen?

greencaps · 2010-01-07T14:18:18.000Z

Ldp:

… Bedenk ook wat er zou gebeuren als je wel knipt, en iemand verplaatst een node buiten het dekkingsgebied. Dit feit zou dan uit de .osc geknipt worden, waardoor de node in onze db niet aangeraakt wordt en op zijn oude plek blijft staan.

Je bedoelt dat een node van binnen naar buiten verplaatst wordt? Ja dat heb ik even over het hoofd gezien eerst. Pas toen ik bijna klaar was dacht ik er aan. Ik zal daar verder naar kijken. Als een node buiten het gebied verplaatst wordt en buiten het gebied blijft is er lijkt me niets aan de hand want die node zit toch niet in je database.

's en 's zijn geen probleem (nou ja afgezien van de genoemde localiseerbaarheid). So wie so zou ik alle s kunnen laten staan want als het er niet in zit kun je het er ook niet uithalen) en de code daarvoor kan ik zo laten. Het addertje zit in de 's. Daar ga ik dan nog over nadenken.

Ldp · 2010-01-07T15:49:53.000Z

greencaps:

Omdat ik geen Benelux polygoon had en er ook niet een aan openstreetmap kon onttrekken ( …dus niemand heeft ooit een Benelux relatie aangemaakt…) heb ik aparte polygonen voor nederland, belgië en luxemburg genomen.

kuch Benelux polygon zoals we die op de server gebruiken

greencaps:

Ja en hoe nu verder. Als ik het goed wil doen dan moeten de onlocaliseerbare ways en relaties in een tweede pass via de API gelocaliseerd worden. Dat is wel te doen natuurlijk maar dat moet dan nog geprogrammeerd worden.

KeepRight doet hetzelfde om na de import nog steeds missende objecten direct uit de API te halen.

greencaps:

Maar eigenlijk zit ik met hetzelfde probleem als wanneer je met een bounding box werkt. Hoe worden dan nu de ways en relations al dan niet meegenomen?

osm2pgsql zal waarschijnlijk de diff actie toepassen op wat er in de db zit, en als het uiteindelijke resultaat buiten de bbox valt, deze niet toepassen, of juist wissen.

En inderdaad, ik doelde op . Deletes en creates zijn inderdaad niet zo spannend.

greencaps · 2010-01-07T20:02:59.000Z

Ldp:

kuch Benelux polygon zoals we die op de server gebruiken.

Dat is schrikken. Kijk dat je wat meer van de Noordzee neemt maakt niet uit. Maar meer dan tien km Duitsland en Frankrijk in de grens zetten is wel gortig. Waarom niet netjes de grenzen zoals ze in osm staan?

Overigens bedankt voor alle reacties en uitleg.

De blauwe polygoon is precies en 1MB. De rode 2 kB.

Ldp · 2010-01-07T23:43:50.000Z

Omdat de wereld niet ophoudt bij de grens? Voor iemand die zowat op de grens woont, zoals ik, zijn de eerste paar km over de grens behoorlijk relevant. En vraag bv eens aan een mapper in Kerkrade of de kaart nog steeds zo interessant is als er niks van Herzogenrath op te zien is.

Er is ook een technische reden, en dat is dat hoe nauwkeuriger de polygon is, dus hoe meer nodes erin zitten, hoe langzamer het uitknippen wordt. Het snelste scenario is een rechthoekige bbox, omdat je dan alleen op min/max lat/lon hoeft te testen. Een redelijk algemene grens, dus de rode in jouw plaatje, is ook nog snel, maar de blauwe zou veel meer rekenwerk kosten.

Wil je het effect zien van direct op de landsgrens afknippen, dan kun je eens de files van http://download.geofabrik.de/osm/ downloaden. Dan zie je ook al snel dat het een knoeiboel op de grens wordt.

greencaps · 2010-01-08T11:49:24.000Z

Is natuurlijk voor een grensbewoner nuttig dat er ook wat van het buitenland op staat. Heb je helemaal gelijk. Sorry ik was even gefocussed op de programmeeruitdaging om precies op de grens te knippen.

En natuurlijk is er verschil bij gebruik van een bbox of polygoon met weinig of veel punten. Ik hoop dat osmosis zo slim is om eenmalig voor een polygoon een bbox te berekenen en vervolgens bij isinarea() aanroepen eerst de lat,lon tegen de bbox te houden. Scheelt echt veel. En dan pas de polygoon zelf langs te gaan als dat dan nog moet.

Om 100.000 's te localiceren gebruikte mijn programma 1:12 m:s met benelux.gpx (24424 punten) en 0:13 m:s voor jouw polygoon(60 punten).

Maar met een truc kan ik toch mijn benelux.gpx gebruiken en kom dan op 0:27. Dus maar twee keer zoveel tijd nodig en haartje precies.

Hierop zie je drie polygonen. In blauw de preciese benelux.gpx en dan nog een outherpolygoon (rood en 60 ptn) en een innerpolygoon (groen en 100 ptn).

De truc is dan dat ik eerst controleer of die buiten het outherpolygoon valt en zo ja dan ben ik klaar. Daarna of die binnen het innerpolygoon valt en zoja dan ben ik ook klaar. Slecht voor lat,lon’s in de grensstreek moet ik dan de polygoon waar het om gaat langs.

Die geofabrik osm files gebruik ik ook wel. Alleen maak ik er geen kaarten van dus valt me ook niet op dat het een knoeiboel is aan de grenzen.

Ldp · 2010-01-08T12:34:42.000Z

greencaps:

En natuurlijk is er verschil bij gebruik van een bbox of polygoon met weinig of veel punten. Ik hoop dat osmosis zo slim is om eenmalig voor een polygoon een bbox te berekenen en vervolgens bij isinarea() aanroepen eerst de lat,lon tegen de bbox te houden. Scheelt echt veel. En dan pas de polygoon zelf langs te gaan als dat dan nog moet.

Nee, zo slim is osmosis niet. Als je completeWays=yes completeRelations=yes gebruikt is het allemaal nog een factor erger, omdat osmosis dan elke node gaat onthouden van je inputfile, omdat later pas bekend raakt of die in een gewenste way zitten. Als je dit dus loslaat op de hele planet, mag je je vastmaken voor een enorm geheugengebruik.

Daarom is er een trucje voor dit geval: eerst een --bounding-box task gebruiken met een ruime rechthoek om je gewenste polygon heen, en daarna pas de --bounding-polygon task. Sinds gisteravond is er zelfs een klein scriptje voor verschenen in SVN.

greencaps:

De truc is dan dat ik eerst controleer of die buiten het outherpolygoon valt en zo ja dan ben ik klaar. Daarna of die binnen het innerpolygoon valt en zoja dan ben ik ook klaar. Slecht voor lat,lon’s in de grensstreek moet ik dan de polygoon waar het om gaat langs.

Trucs gebruiken om te versnellen zijn prima. Het is het uiteindelijke resultaat dat telt.

Ldp · 2010-01-11T22:39:30.000Z

De planet-benelux is afgelopen nacht opnieuw geladen, zodat alle opgebouwde ‘zooi’ buiten de Benelux verdwenen is.