Die tile 10010038 is niet een verbeterde maar ik heb de oude tile laten zitten, omdat er iemand aan de kustlijn heeft lopen klooien eind september waardoor de boel onderwater is komen te staan op mijn garmin kaart van 1 oktober. Voor degene die perse die nieuwe tile nodig heeft om zijn/haar wijzigingen te zien heb ik 'm maar apart op de site gezet, maar daarop staat dus die fout in osm en is alles blauw. De online kaarten hebben geen probleem met die weergave, maar de Garmin kaarten wel.
@ligfietser, waar verklaar je dan uit dat de aangegeven gebieden er op de OSM basiskaart er wel goed uitzien, min of meer als gescheiden ‘sloten’, maar specifiek op de OpenFietsmap als een aaneengesloten watervlak, zelfs dwars over huizen heen?
Op de OFM zag ik in de verschillende versies dat er een overstroming was op het landgoed Dordwijk langs de zuidzijde van de N3 (randweg Dordrecht). In openstreetmap.org was het landgoed overigens keurig groen op te zien. (park)
Nu ik “dacht” iets verder te zijn dan het tekenen van simpele weggetjes probeerde ik hier een oplossing voor te vinden. Nee dus. Denk dat ik de boel verziekt heb.
Krijg het niet voor elkaar een eiland tevoorschijn te toveren.
Kan ik nu beter wachten tot de nieuwe 3dshapes erover heen komen de komende we(e)k(en) voor dat ik verder “klooi”?? Het park was overigens al 3dshapes. Er geldt overigens “geen toegang” hier dus niemand zal natte voeten krijgen.
Advies opgevolgd door van de betreffende inner polygons de tag “natural=water” te verwijderen. Het ziet er nu in Potlach daardoor wel vreemd uit met dikke lijnen. Gaat dit wel goed?
Zie ook de post van @eggie hiervoor. Mij lijkt dat er meer aan de hand is geweest bij het genereren van de OFM 01-10-2010. Ik zal de vorige versie even opnieuw installeren ter vergelijking…
Edit: Op de versie 03-09-2010 zijn de ‘overstroomde’ gebieden er ook! Eigenlijk wel logisch als de foutieve tags er al vanaf 2007 in zitten. Dat zeker weten van mij was dus niet zo zeker…
Omdat de Garmin kaart de tag natural=water als water ziet, en dus ook zo rendert. Kennelijk zijn de osm basiskaarten slimmer en renderen ze alles wat binnen de multipolygoon relatie is niet als water. Kijk maar naar de relatie http://www.openstreetmap.org/browse/relation/1518 Alle eilandjes die als ‘inner’ zijn getagd en ook nog de tag natural=water hebben staan op mijn kaart onderwater, maar niet op de basiskaart. Ik zie dat je een aantal tags al hebt verbeterd.
Ik heb van het park (eiland) en het water eromheen een multipolygon relatie gemaakt met het water als outer en het park/eiland als inner, ik denk dat het zo wel goed komt: http://www.openstreetmap.org/browse/relation/1206036
Zal best wel eens kunnen dat je nog rare dingen tegenkomt, die laatste kaart was een zware bevalling. Ik weet niet wat er met de geofabrik uitsnede van Europa van afgelopen vrijdag aan de hand was maar het verwerken duurde een uur of 5-6 ipv de gebruikelijke 2 uur. Ze zijn de kaarten ook in een heel ander formaat (pbf) aan het aanbieden, geen idee hoe ik die moet inlezen.
@ligfietser,
Elders had ik het ook al gepost dat de 01-10-2010 versie van de OFM op mijn Colorado nu ook aanmerkelijk traag reageert. Ik bedoel meedraaien met de koers, dat gaat veel trager dan voorheen. Ook de grootte is meer toegenomen dan bij vorige updates. Symptomen… waarvan?
De kaart wordt telkens groter en zwaarder door de 3d import. Ik moet nu regelmatig de tiles halveren of zelfs in drieeën splitsen omdat ze anders domweg niet gecompileerd kunnen worden.
Ik hoop dat de OFM niet te zwaar wordt. De OnRoute Wandelkaart is voor mij bij het (race)fietsen hierdoor ook minder bruikbaar. Voegt de 3d import iets toe aan het specifieke doelgebruik als fietskaart en zo niet, zou er dan een optie zijn om die 3d data te negeren/uit te filteren bij het compileren?
Ik vind het wel meevallen, zelfs op mijn oude Etrex doet de kaart het nog steeds in de regio Utrecht waar alle 3d import al is voltooid.
Ok de beeldopbouw is een stuk trager dan bijv dan pakweg in de Balkan (daar ook veel profijt gehad van de osm kaart overigens) maar hij doet het nog wel. Natuurlijk is het mogelijk alle topo data eruit te slopen maar dan zie je alleen wegen.
Jouw idee is zo gek nog niet, jammergnoeg ondersteunt Mapsource het gebruik van layers niet, zoals op de gps wel kan. Een transparante kaart met wegen bovenop een topokaart bijvoorbeeld zou goed kunnen op de gps, maar mapsource laat dan een van beide zien. Er zijn osm garmin kaarten die uit diverse lagen zijn opgebouwd, bijv deze: http://www.cferrero.net/maps/map_downloads.html
Nadeel is dus dat je niet alles in een kaart in Mapsource kunt zien.
Zou je niet iets kunnen doen met het detail-niveau - dat gaat toch ook via de lagen en dat werkt zowel in MapSource alsook op de GPS? Als ik kijk naar de Garmin Topo Benelux dan is er een groot verschil in details, met name in de terrein-kenmerken, als je schakelt tussen het meeste of het minste detail. Bij de OpenFietsMap verdwijnen alleen de POI’s (voor zover ik even snel kan zien) als je kiest voor het laagste detailniveau. Komt dat door het gebruik van mkgmap bij het compileren van de OFM, terwijl Garmin misschien andere tools gebruikt? En wat de TYP-file nog in zich heeft om de lagen aan het detailniveau te koppelen, weet ik niet, maar misschien het uitzoeken waard?
Ja, dat is een goede suggestie. Nu recentelijk er zoveel landgebruik is bijgekomen zal ik daar eens naar moeten gaan kijken. Op het allerlaagste niveau zie je nu nog steeds bijv alle bossen, misschien moet ik die op een wat hoger niveau al uitschakelen. En op een iets minder laag niveau grasland e.d. al weglaten, dat scheelt wellicht een hoop in snelheid waarmee de kaartbeelden ververst worden op de gps.
De overstroomde gebieden zijn in de laatste versie weggewerkt, dank voor jouw bijdrage hiervoor!
Ook in NO Groningen is de kustlijn weer hersteld en het park bij Dordrecht ziet er weer goed uit.
Ik heb nog (veel) meer overstroomde gebieden gevonden en er blijken twee scenario’s gebruikt te worden om die te ‘taggen’:
1.
Een outer multipolygon met tag natural=water waarbinnen een inner multipolygon met tag natural=water. Dit is te corrigeren door bij de inner polygon de tag 'natural=water te verwijderen. Neveneffect hiervan is dat in Potlatch 1.4 de inner polygon nu met dikke lijnen is gemarkeerd. De OpenFietsMap rendert dit vervolgens correct.
2.
Een outer multipolygon met tag natural=water waarbinnen een inner multipolygon met tag natural=land. De inner polygon is gemarkeerd met dezelfde dunne lijn als de outer polygon. De OpenFietsMap rendert dit ook correct.
Mijn vraag: wat heeft de voorkeur en waarom: methode 1 of methode 2 die er dus op neerkomt dat je in voorkomende situaties van de inner polygon de tag natural=water wijzigt in natural=land?
Op enkele plaatsen (o.a. Rottemeren bij Zevenhuizen Z-H en Bleiswijk) heb ik methode 2. gebruikt, eigenlijk om te kijken wat hiervan op de OFM het effect is.
Methode 1 en 2 kan allebei, maar ik zou niet gaan taggen omdat het leuk staat in potlatch (of op de ofm) want de stelregel op osm is ook dat je niet moet gaan taggen voor de renderer.
Ik heb de ofm aangepast dat natural=land ook wordt gerenderd in dat soort gevallen. Ik kan 'm echter niet aanpassen aan de situatie dat natural=water ook bij de inner polygons staat.
Die laatste situatie is echter sowieso fout, hoewel de online renderers dat kennelijk wel goedkeuren. Ik zou gewoon de tag weghalen, is het minste werk. Wat je natuurlijk wel kan doen is het landgebruik op zo’n eilandje (landuse=grass, farm of residential o.i.d) taggen ipv “land”.