Mag het een tegeltje minder zijn a.u.b.?

Als ik een verse Nederland en Frankrijk ophaal bij http://garmin.openstreetmap.nl/ dan klaagt de JaVaWa Device Manager altijd.
Terecht, er zit namelijk een tegel in, die in beide mappen wordt gebruikt.

Wat ik meestal doe is, via manual tile selection, de dubbele tegel uitzetten en Frankrijk opnieuw laten uitrekenen.
Eigenlijk zonde van de CPU cycles op de server.

De tegel is voor 99% van België en pakt een klein stukje Zeeland mee.
Terecht dat hij dus in Nederland zit.

Maar waarom zit deze tegel in Frankrijk?
Er zit geen millimeter Frans grondgebied in. :frowning:

Overigens kunnen er nog meer tegels uit Frankrijk.
Aan de noordzijde en oostzijde van Frankrijk zitten tegels die volledig buiten Frankrijk liggen.
Maar de tegel in Gent is echt onhandig.

Vandaar de titel, mag het een tegeltje minder zijn a.u.b.? :wink:

Ik weet niet precies hoe de scripts van Lambertus in elkaar zitten, maar naarmate OSM groeit, worden de tegels steeds kleiner omdat die aan een maximum aan data gebonden zijn.
Maw het worden er steeds méér. :wink:
Heb net gemerkt dat de OFM Benelux zojuist de 100 tegels is gepasseerd, niet zo lang geleden waren het nog zo’n 70. Met de invoering van de BAG data gaat het echter heel hard.

Hehehe, meer tegels dus. :stuck_out_tongue:

Nu snap ik waarom Parijs uit zoveel kleine tegels bestaat.
Veel data op een klein oppervlak.

Maar het aantal maakt natuurlijk niet uit, als er maar geen dubbelingen in zitten.
De “dubbele” tegel Gent hoort niet thuis in de Frankrijk map.
Als ik hier een beetje rond lees, dan schat ik meneer Lambertus in als een handige gast. :wink:
Moet lukken. :smiley:

Om te bepalen welke tegeltjes er nou bij een land horen heb ik ooit een boel poly bestandjes van het internet geplukt (bijv. bij Geofabrik). Die poly bestandjes zijn tekst bestandjes waarin 1 of meer vierkantjes en polygonen gedefinieerd zijn die ruwweg een land beslaan. Vervolgens heb ik een script (matchit.php) geschreven die voor elk tegeltje bepaalt of het (deels) in een poly bestandje valt. Daarin gebruik ik een PHP klasse die de polygoon berekeningen doet.

Ik zie derhalve twee mogelijke oorzaken:

  • de poly is te onnauwkeurig
  • het algoritme dat tegels matched met poly’s gaat de mist in.

Nederland gaat perfect maar bijv. Belgie heeft ook een paar tegeltjes teveel. Het algoritme vertrouw ik wel, dus blijft de poly over. Dit is een oud plaatje van Belgie dat gemaakt is door het matchit script:

zwart: een vierkant om de poly heen dat dient als prefiltering (je wilt snel het grootste deel van de tegeltjes kunnen negeren anders duurt het matchen heel lang)
blauw: de vierkantjes in de poly die Belgie moeten voorstellen (hiermee wordt in detail de tegeltjes gematched die door de pre-filtering heen komen)
rood: de geselecteerde tegeltjes die volgens het algoritme (deels) in Belgie liggen. Dit is een oud plaatje, toen waren de tegeltjes nog groter.

Als je naar de blauwe vierkantjes kijkt zie je dat die best grof zijn. Als je naar de Geofabrik pagina kijkt dan zie je dat die grens heel fijntjes is.

Conclusie: mag het een coördinaat in een landdefinitie meer zijn?

Ik zal de Frankrijk en Belgie poly’s eens updaten en dan bij de volgende update het resultaat bekijken.

Lambertus, zou je ook de landsgrens als poly bestand kunnen gebruiken?
Hier bv eentje met alle landen:
http://www.rjruss.info/2010/12/free-countries-of-world-in-polygon-kml.html
Edit: deze is denk ik niet geschikt, veel te grof. Denk dat die van geofabrik beter is.

In principe is de gebruikte polygoon klasse bestandsonafhankelijk. Mijn matchit script zou in plaats van een poly ook een KML in kunnen lezen maar ik zie het voordeel niet, er is van elk land al een poly.

Nauwkeurigheid is niet heel belangrijk, een te hoge nauwkeurigheid is nadelig vanwege de hoge cpu resource verbruik. 2000-3000 tegeltjes per kaart vergelijken met circa 300 landen/staten duurt nu al zo’n 50 minuten. Met veel complexere polygonen kan dit nog wel eens een veelvoud worden. Bovendien moet dit werk voor elke kaart gedaan worden. Maar dit wordt nu nog allemaal op 1 niet al te snelle cpu core gedaan, idealiter wordt dit rekenwerk over 3 of 4 cores verdeeld.

Generic:
belgium: matching 2575 tiles against 13 polygons resulted in 65 preliminary and 44 final matches in 3.39 seconds.

Generic new:
belgium: matching 2160 tiles against 13 polygons resulted in 65 preliminary and 44 final matches in 2.88 seconds.

Kr@bs, ik heb het even getest, maar dubbele tegels hoeven niet altijd een negatief effect te hebben op de weergave.
Heb de landenset van België en Nederland op de gps gezet maar zie geen rare dingen, de grensstreek (met veel dubbele tegels) is gewoon te zien.

Bij mijn OFM Duitsland+Benelux zit het Benelux deel wel in de weg met de gewone OFM Benelux (zelfde tegels). Hoe dat dan komt is nog de vraag, moet ik nog uitzoeken. :confused:

Knap ingewikkeld dus, als ik dat zo lees.
Ik ben benieuwd naar het resultaat van de test. :slight_smile:

Klopt, maar routeren kan een probleem zijn.
Op mijn Dakota 20 een kaart uitzetten met een dubbele tegel is een probleem.

Andere kaarten die dan nog aan staan geven routerings problemen in de bewuste tegel.
(Die tegel staat dan stiekem ook uit.)

Dan zouden we die tegels bij de gmapsupp generatie dus eigenlijk moeten hernummeren.
Gmaptool heeft daar een optie voor dacht ik, maar heb dat nooit uitgetest.
Simpelweg hernoemen van de img files gaat helaas niet omdat het nr ook in de tegel is “meegebakken”.
Vooralsnog is de oplossing dus of een custom mapset laten genereren, of met osm combiner aan de slag.

Als het mogelijk is om onder linux eenvoudig een tegel intern te hernoemen, dan wil ik best een poging doen om dit in in de scripts te bakken.

Met gmaptool zou je een tile kunnen hernummeren, http://www.gmaptool.eu/en/content/change-mapid
Ik weet echter niet of twee verschillende tiles met identieke inhoud de routering verstoren, moet dat eerst nog eens uittesten.

Zo doe ik het inderdaad nu, een custom mapset laten genereren en op de GPS zetten.
Echter omdat ik weet dat dit probleem speelt met een aantal Garmin toestellen.

Ik weet niet of dit de weg is om te gaan.

Als ik b.v. Frankrijk en Nederland tegelijk binnen haal en op de GPS zet, dan gaat het goed op de “Gent” tegel na.
Als je enige tijd later Frankrijk laat voor wat het is en je haalt alleen een verse Nederland binnen, dat is kansloos.
De tegelnummers rouleren blijkbaar.
Dit geeft een bak ellende met een heleboel dubbele tegels.
(Ik haal dus altijd FR en NL tegelijk binnen, vanwege de roulerende tegel nummers.)

Als je een enkele tegel gaat hernoemen, haal je volgens mij deze ellende alleen maar meer op de hals.

De beste methode is toch de landsgrenzen scherper krijgen, of accepteren zoals het nu is.

Als de tegels hernoemd worden dan zouden deze beginnen met de kaart type en landcode en dus altijd uniek zolang je niet meer dan 1 versie van hetzelfde land op je GPS hebt staan. Dan zou het toch goed gaan, of niet?

Dus i.p.v. 63xxxxxx.img krijg je dan bijv. 22108xxx: generic (22), belgie (108).

Je zou het aan popej kunnen vragen, de maker van gmaptool.
Ik weet niet of en hoe je met de command line versie gmt.exe die tegels kan hernummeren en of dat onder Linux ook draait?

Dat zou goed moeten gaan.
Als dat nummer in andere landen niet gebruikt wordt zie ik geen probleem.

Ik heb een testje gedaan door de Map ID’s mbv gmaptool te verminderen door de FID+000 (=24056000 is ook de overview mapname) eraf te halen.
B 63241878-24056000=39185878
NL 63241878-24528000=38713878

gmt.exe -w -e -24056000 6324*.img

Gmaptool houdt de tegelnummers hetzelfde alleen de interne hex code past die aan. Javawa device manager geeft ook geen foutmelding meer. Ik krijg alleen geen route als ik beide kaarten geselecteerd heb (maar dat is sowieso niet aan te raden).
Schakel ik er eentje uit dan lijkt het goed te routeren. Kortom ik denk dat dit een goede aanpassing is.

Nice!

Het is inderdaad een andere benadering van het probleem, maar ik denk een prima oplossing!
Zoals het lijkt kijkt de Garmin dus naar de interne hex codes.

Als je Nederland en Frankrijk binnen haalt, 1 map uitzet, en je kan routeren in Gent, dan moet het goed zijn. :sunglasses:
Wat ik begrijp schakelen alleen de wat oudere Garmin toestellen de dubbele tegel(s) uit in alle mappen. (Routeren.)
Dus niet iedereen zal er tegenaan lopen.
Van de Garmin Dakota 20 weet ik dat dit probleem speelt.

Bv in NL en Belgie zie ik sets met nummers in de range van 632418xx - 632419xx. Als er dan toevallig ook een tegel met 632420xx langskomt zijn dus de laatste 4 cijfers variabel en dat past niet. De Family ID’s hebben immers alleen de laatste 3 cijfers “vrij” want de eerste 5 cijfers zijn vast (2 maptype+ 3 landcode)

Dus dan ik denk dat tegelnummer - mapnummer het beste is, de kans dat een van die cijfers overlapt met een kaartenset van een andere mapleverancier is aanwezig maar erg klein.

@Kr@bs, het probleem doet zich ook voor op de nieuwere Garmins, bv op de Oregon 600.