October 2011 - mkgmap-dev - The mkgmap lists

uisng wildcards in names
by n Willink 16 Oct '11

16 Oct '11

Is it possible to use wildcards in names as part of a style sheet so only one type is needed? ie amenity=fuel & operator=Sainsb* [0x6000 resolution 19 continue ] this would also allow for misspellings? -- View this message in context: http://gis.638310.n2.nabble.com/uisng-wildcards-in-names-tp6897823p6897823.… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 8

add-pois-to-areas entrance as option
by Olaf Hasemann 16 Oct '11

16 Oct '11

First, thanks for the new POI generation from multipolygon and polygons. It seams to work fine and changing my style files was easy. There is only one thing i am not happy with: the use of building=entrance as the default position for the POI of a polygon. In urban areas there are often buildings, pedestrian areas, subway entrances ... mapped over each other as polygons and all of the generated pois fall to the entrances of the buildings, often two or more at the same position. IMO the solution would be to disable the use of the building=entrance by default and if requested specify one or more key/value pairs as an additional argument to the add-pois-to-areas option. thanks in advance hasemann -- Olaf Hasemann e-mail: o.hasemann(a)gmx.de

2 1

Coastline issues - analysis and possible solution
by Bartosz Fabianowski 15 Oct '11

15 Oct '11

Hi list I spent the last 12 hours debugging sea generation problems in Europe. After digging through a lot of mkgmap and splitter code, I believe I understand the source of the issues now. Since data is processed in tiles, the sea generator will often encounter coastlines clipped at the tile boundaries. There are heuristics in the code that should produce valid sea multipolygons for tiles with incomplete coastlines as well. However, the heuristics fail for the Geofabrik extracts of several European countries. Here is what I believe the problem to be: The sea generator correctly identifies incomplete coastlines. It then attempts to determine for each such coastline whether it was clipped by a tile boundary. It is this test that fails for some countries, leading to missing or inverted sea. The source of this issue can be traced back to the splitter. Here, tile boundaries are expanded to coarse multiples of Garmin map units. Tiles therefore become larger than originally requested. If map data for the entire expanded area is available, this is OK. But when dealing with country extracts, there may be no data available for some of the expanded regions. Here is an ASCII art example, a rectangular extract with a coastline inside, shown as a double line: +---------+ | | | | |=========| | | +---------+ If this data is fed to mkgmap directly, the sea generator will correctly determine that the coastline was clipped by the left and right tile boundaries. If the data is passed through the splitter first, even if no splitting into multiple tiles should be needed, the tile boundaries are rounded to the multiples of Garmin map units mentioned above. The tile may thus grow: +-----------+ | | | | | | | ========= | | | | | +-----------+ The problem is that now, the coastline no longer touches the tile boundaries. The mkgmap sea generator is confused by this and produces invalid or no sea at all. An obvious but incorrect solution is for the sea generator to check whether the coastline reaches the *original* tile boundary, not the rounded one. This would require the splitter to pass the original boundary to mkgmap along with each tile. The real issue with this solution would be that even if mkgmap correctly detects a clipped coastline, there is no valid data between the original and rounded boundaries. To construct a proper sea multipolygon, mkgmap would have to synthesize a coastline in that space, likely introducing ugly artifacts. A correct solution, already implemented in mkgmap today, is to read coastlines from a separate file. The file should contain coastlines that extend at least as far as the rounded tile boundaries. From the mail archives, it appears that WanMil has identified the same issue before and proposed this very solution [1]. Coastlines for a larger area can be extracted using: osmosis \ --rb larger_area.osm.pbf \ --tf accept-ways natural=coastline \ --tf reject-relations \ --used-node \ --wb coastlines.osm.pbf omitmetadata=true The coaslines.osm.pbf file can then be fed to mkgmap via the --coastlinefile option. While WanMil described this solution in December 2010 already, it seems to have been buried in the mailing list without becoming common knowledge. Another mailing list post [2] shows that the --coastlinefile had been broken for a while without anyone noticing, confirming that it is not in common use. After spending 12 hours on this today, I hope that others will benefit from this write-up instead of having to repeat my odyssey. Anyone wanting to use the --coastlinefile option will require coastlines for a larger region than the extract they are processing. While the option does allow several files to be specified whose contents are then concatenated, it is easiest to load a single file with coastlines for a larger area. I have prepared two such files, one from today's Geofabrik europe.osm.pbf extract, the other from the most recent planet-latest.osm.pbf. Both files can be found at [3]. I am providing these files so that anyone working with extracts can download compact coastlines only instead of having to extract them from the huge europe.osm.pbf or planet-latest.osm.pbf files. Right now, the files were generated once-off. If they are found to be useful by others, I am happy to automate the process and make updated coastline files available on a regular basis. Finally, a word of warning: When using coastlines_planet.osm.pbf, mkgmap needs a *lot* of memory. I found that even for small tiles, 4.5GB of RAM are consumed by the Java process. With coastlines_europe.osm.pbf, the memory consumption is about 2.5GB. - Bartosz [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q4/009636.html [2] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010138.html [3] http://www.fabianowski.eu/osm/coastlines/

7 27

Memory Consumption on Index Creation
by Felix Hartmann 15 Oct '11

15 Oct '11

1. I noticed that (at least for my style-file) 7500MB of RAM available does not suffice to compile a map of Europe including index! However if I recreate the index in another go, then it is no problem. How comes? The index creation seems to be completly independent of the maptiles creation. Is mkgmap leaving stuff inside the memory, that is in reality not needed anymore? 2. Also as running out of memory primarily happens on index creation, it would be great if mkgmap writes out the index under a temporary name, and once it has passed correctly, renames the file. Else it is not possible to easily assess in a bash/batch script whether mkgmap completed the map correctly or not (and hence one uploads broken maps if everything automated). Or at least I don't see any way to find out whether it passed correctly or not.

6 26

Bizarre flooding in South Wales
by Steve Hosgood 15 Oct '11

15 Oct '11

Last week I generated a routable map for South Wales which does everything you'd expect concerning routing just fine, but suffers the well-known "flooding" problem. Symptoms are a bit odd - it's not as if the flooding merely follows the coastline on the wrong side or anything. Just south and east of Swansea University for instance is a point where the sea seems to "turn inside out" and to the east (for a while) things are OK, but to the west the sea starts to grow outwards over the land. At the "turn inside out" point, the sea to the east has contracted to a point, and to the west the sea spreads from that point (on the land). The point itself looks like two sea triangles touching at their shared apexes. (This is viewing it on a Garmin Streetpilot, no idea if it looks like that on MapSource or anything). Another oddity is that on the west, the incorrectly spreading sea almost seems to be following a false coast slightly inshore of the real one for a short while. Then it floods everywhere. I can put up the original .pbf files, tile .pbf files and the eventual .img file for this situation if anyone is interested. Steve

4 14

Routing not working
by Carlos Dávila 15 Oct '11

15 Oct '11

I have compiled a map of India from Geofabrik extract, using the commands below, similar to the ones I use for other countries. The map compiles without errors but routing doesn't work on MapSource, only a straight line is drawn from point A to B. I have tried with different days extracts with the same result. I also tried reducing the parameters in the mkgmap call to the minimum, but still the same result. Any idea why routing is not working? java -Xmx1500M -jar splitter.jar --max-nodes=1400000 --mapid=55180001 india.osm.pbf java -Xmx1200m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --tdbfile --latin1 --code-page=1252 --gmapsupp --country-name=India --country-abbr=IND --area-name=India --family-name="OSM India" --family-id=18 --product-id=1 --series-name="OSM-India" --overview-mapname=55180000 --index --ignore-maxspeeds --remove-short-arcs --merge-lines --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=bounds,is_in,nearest --drive-on-left --check-roundabouts --check-roundabout-flares --style=mio -c india.args

3 12

Address search on multi-tile multi-layer maps not working
by Carlos Dávila 15 Oct '11

15 Oct '11

I have a map built with the following command: java -ea -jar mkgmap.jar --output-dir=../mapas/portugal/ --show-profiles=1 --gmapsupp --latin1 --series-name="OSM+SRTM Portugal" --family-id=122 --product-id=1 --family-name="OpenStreetMap Portugal" --area-name="Portugal" --index ../mapas/portugal/55220001.img --family-id=322 --product-id=1 --family-name="Curvas nivel Portugal" --description="SRTM-Portugal" ../mapas/portugal/65220001.img 6522000*.img are prebuilt tiles with SRTM contour lines and 5522000*.img are prebuilt tiles containing OSM data. This map works fine in MapSource, but if I compile more than one srtm or osm tile, keeping all the rest of the comman unchanged, any attempt to search for a city or POI (Ctrl+F) causes an error: MPL_MAP.CPP-918-6.13.7.0 Map: 65220001 Error code: 1 Address search doesn't find any of the listed streets I look for. Has anyone search capability in a similar multi-layer and multi-tile map working? Regards Carlos

1 0

Oneway road goes nowhere
by flabot＠googlemail.com 15 Oct '11

15 Oct '11

Hi ! I use the options --report-dead-ends=2 and have a lot or error warning like this one : Oneway road (http://www.openstreetmap.org/browse/way/116845081) goes nowhere at http://www.openstreetmap.org/?mlat=28.46077&mlon=-16.30457&zoom=17 The problem is that there are a lot of highway=service, onway=yes that goesto or come from a amenity=parking area. Perhaps mkgmap can check if oneway com/go to parking-areas ? The quick way can also be to make a --report-dead-end=3 , doing the same as =2 but filter highway=service ? If you need more log ... http://dev.openstreetmap.de/aio/mkgmap-errors/ thx for your great work out there

2 1

[PATCH v1] Using name-tag-list for country names
by WanMil 15 Oct '11

15 Oct '11

Up to now the names of the countries were taken from the LocatorConfig.xml file no matter what has been configured in the name-tag-list option. But the name-tag-list option was used to get the country names from the precompiled bounds which causes a problem if country name in the special language is not contained in the LocatorConfig.xml. The patch now uses the name-tag-list consistently for all places where country names are standardized. Additionally the values in the LocatorConfig.xml are automatically completed by all name tags of the precompiled boundaries. http://files.mkgmap.org.uk/detail/37 links to r2047 including this patch. WanMil

4 10

Commit: r2049: Reimplementation of the add-pois-to-area option
by svn commit 13 Oct '11

13 Oct '11

Version 2049 was commited by wanmil on 2011-10-10 19:37:26 +0100 (Mon, 10 Oct 2011) Reimplementation of the add-pois-to-area option The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file.

7 11