Re: [mkgmap-dev] delete and replace is_in:country tags
Hello
On 16/02/11 03:01, maning sambale wrote:
*=* {delete is_in:country=disputed territory}
place=* {add is_in:country=Philippines}
If you want to replace all disputed's with Philippines then
this will do it:
is_in:country='disputed territory' {set is_in:country=Philippines}
If you want to be more selective you could do:
is_in:country='disputed territory' {delete is_in:country}
or..
place=* {add is_in:country=Philippines}
The --country-name=Philippines and --country-abbr=PL options should be
used with mkgmap to set the default country too.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] java.lang.IllegalArgumentException
Hi, with the mkgmap sr1846 I see now this java exception: Exception in thread main java.lang.IllegalArgumentException at java.nio.ByteBuffer.allocate(ByteBuffer.java:311) at uk.me.parabola.imgfmt.sys.Directory.sync(Directory.java:176) at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:230) at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:240) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:119) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:127) Don't know if this is serious, at least the process finished and I get a map which works fine for my region. It's SUN Java 1.6.0_23-b05 It this something introduced with the last mkgmap changes, something broken in the OSM file or a problem with my config? Thanks, Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] java.lang.IllegalArgumentException
On 16/02/11 09:50, Thorsten Kukuk wrote: Hi, with the mkgmap sr1846 I see now this java exception: Exception in thread main java.lang.IllegalArgumentException at java.nio.ByteBuffer.allocate(ByteBuffer.java:311) at uk.me.parabola.imgfmt.sys.Directory.sync(Directory.java:176) at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:230) at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:240) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:119) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:127) Don't know if this is serious, at least the process finished and I get a map which works fine for my region. It's SUN Java 1.6.0_23-b05 It this something introduced with the last mkgmap changes, something broken in the OSM file or a problem with my config? This is happening during writing out the gmapsupp.img file. It is unlikely that the file is complete even if it is slightly usable. I don't know what causes it, there are several possibilities for example if it is over 2G in size. But the last time it was reported that was not the problem. There was a recent thread here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010089.html ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search and index.
On 15/02/11 18:16, WanMil wrote: 1st problem: Splitter (as you already mentioned) The tiles do not contain the full information for multipolygons that exceed the tile bounds It may be possible to pre-process the planet file to divide the world into (say) 1° by 1° squares and pre-tag each one with any outer bounding-polygon information which applies to the whole of that tile. When a splitter produces an output file it will know that level of information instantly... I like the idea of creating smaller tiles with consistent information. I would not implement this in splitter. I have implemented the multipolygon algorithms for mkgmap and that was hard work until it reached the current quality. Handling boundary data is nothing else than multipolygon handling. We don't need to reinvent the wheel and can use mkgmap (at least the mkgmap codebase) to do that. Excellent. After further thought I suspect that my idea of 1° x 1° tiles would be too big - you'd want to choose a tile size so that several would be used to create a typical user's request from the splitter. By the way: The coastlinefile processing has not such a mechanism. It simply loads all coastline data from one file and keeps that in memory. That's not a good choice for large areas. This could be tuned. Yeah - I'm surprised it doesn't do that already. I would propose a suite of sanity-checker programs that should be periodically run over the planet file looking for broken polygons. Ok, that's not mkgmaps task. There are already some fine tools like the WayCheck suite. Maybe they could be tuned to do that. In the end people will set more value on valid boundary data if mkgmap makes use of it. That's true - and remember it won't just be used by mkgmap. If (when?) there is ever a mktomtommap project, they would need it too. So would the slippymap gazetteer and any route-planner software. It should be easier to maintain than the coastline data because the political (or adminstration??) bounding polygons should obey certain rules that could be checked automatically. Can you give an example? I don't see why it should be easier than coastline checking. 1) A bounding polygon ought to form a closed way. Coastlines seem to be composed of many open ways that happen to share end-points (more like roads). That latter fact makes it harder to check a coastline since a way flagged as coastline of France will at some point share endpoints with a way flagged as coastline of Spain, and that's true but not checkable automatically. 2) A bounding polygon's name ought to be unique within its own parent bounding-polygon. If for some reason you really want two bounding-polygons to be disjoint, but refer to the same logical place, you'd put them both in a relation. 3) There should not be an intersection of two bounding polygons at the same level. In other words, two towns can't intersect. 4) There are such things as cities that span multiple counties (like London, England for instance). There needs to be rules to allow that, maybe where the bounding-box for the majority of the county of Middlesex is required to be entirely outside the bounding box for London, but a second bounding-box (also flagged as 'county of Middlesex') is placed inside the bounding-box for London, but a member of a relation with the other Middlesex to prove that they are supposed to be the same. If the 'relation' was omitted, the auto-checkers would barf because you'd have two disjoint places called Middlesex inside the same parent bounding box (England). (You might choose to relax that rule if the two Middlesex bounding-boxes shared one or more periphery vectors, as they would here.) 5) The political:layer tags should increase in value as the bounding-boxes nest. In the unusual case of enclaves that I mentioned in my earlier post, you allow the layer value to break that rule (within the enclave the inherited knowledge of the parent bounding boxes is forgotten), but there has to be a tag to say political:enclave=yes or something to let it happen without the auto-checher barfing. 6) Er - there must be more! The outer boundary for a land-locked country will consist of a LOT of data, agreed. For island nations it will be vastly less because you can draw a crude polygon off-shore to encompass all the land area. And you'd have to do that, because you want to include all the minor off-shore islands. You want an extreme example, look at Greece! But the outer polygon for Greece might not be all that detailed yet still do the job correctly - except for the northern land-border of course which will be crazy. Sounds easy although I have no idea how to put that into a good algorithm that does not exhaust common memory and processor configurations. Example: * How do you want to detect island nations? Sorry - I didn't make myself clear. No-one has to detect island nations. Some mapper draws the polygons! But the mapper will have an easy time
Re: [mkgmap-dev] delete and replace is_in:country tags
On 16/02/11 10:20, maning sambale wrote: Thanks! Now I have two countries to choose from Philippines and PHI. Better that the last one. OK I am adding the Philippines to the LocatorConfig file so you should have only one to choose from once it is checked in. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] delete and replace is_in:country tags
Thanks. Just to correct my last message, ISO shortname should be PHL On Wed, Feb 16, 2011 at 6:25 PM, Steve Ratcliffe st...@parabola.me.uk wrote: On 16/02/11 10:20, maning sambale wrote: Thanks! Now I have two countries to choose from Philippines and PHI. Better that the last one. OK I am adding the Philippines to the LocatorConfig file so you should have only one to choose from once it is checked in. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] --make-cycleways labels invisible
Hi, If I use the option --make-opposite-cycleways or --make-all-cycleways, an extra label is placed with street (cycleway). Is it possible to turn this label off or make it invisible in the style line file and how? Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address city country name assignment.
Am 16.02.2011 11:32, schrieb Christian Steins: On Wed, 16 Feb 2011 08:00:48 +0200, Du Plessis, Bennie wrote: I don't understand which tags are used to find the country (and other address data) for a street, or city to use in address search. I think we should have a wiki page describing all this. -how do the different location-autofill options work? -what is the algorithm for getting the region for a place? -how are streets assigned to cities? -what is the purpose of the LocatorConfig.xml file? Don't forget the importanrs point: How to use it. :-) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search and index.
4) There are such things as cities that span multiple counties (like London, England for instance). There needs to be rules to allow that, maybe where the bounding-box for the majority of the county of Middlesex is required to be entirely outside the bounding box for London, but a second bounding-box (also flagged as 'county of Middlesex') is placed inside the bounding-box for London, but a member of a relation with the other Middlesex to prove that they are supposed to be the same. If the 'relation' was omitted, the auto-checkers would barf because you'd have two disjoint places called Middlesex inside the same parent bounding box (England). (You might choose to relax that rule if the two Middlesex bounding-boxes shared one or more periphery vectors, as they would here.) Middlesex is not a county any more, it's a historic county which doesn't have a place in any administrative hierarchy. Same with Berkshire and Avon, for example. A polygon to represent Middlesex doesn't need to bear any relationship to the boundary of Greater London, various London Boroughs, Hertfordshire etc. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address city country name assignment.
I don't understand which tags are used to find the country (and other address data) for a street, or city to use in address search. [First I should say that I did not write any of the code in question and haven't looked at it much at all so I don't really know how it works in any detail] It should use the is_in tags where they are present. If they are not it tries to find something nearby with tags and use them, that depends on the autofill option. It is fundamentally unreliable though since this happens after tiles are split, and tiles are processed one at a time. So even in cases where the closest town is correct, if it happens to be on another tile it will not be found. I understand the address search function is still shaky, but can you say where a point / way will get its country info from? Ha! I think it was shaky, but now it is solid enough to expose the lack of good data or processing of the data that exists. With the city nodes containing the wrong country name, I suppose any street near it gets assigned that incorrect country name. Yes, probably. Will it help to play with is_in tags with the style files, or is the index created before the style file changes are done? It might help, the index is created last, but all the information that it requires is in the tiles themselves. Is boundary information considered at all? Because boundaries in my map is still faulty. A lot of boundaries are not rendered by mkgmap. Some No, boundary data isn't used for this. I know nothing of code language, but would like to read through it anyway. Where can I see the code that assigns the address info to the street / cities? There is code in StyledConverter.java Locator.java MapBuilder.java It is quite likely that there are bugs or that it doesn't quite work in the intended way. I found a bug just by looking at the code while researching this answer! It would probably be best to start with a tiny OSM file, containing only cities, then add a few streets, POIs as you work out what is happening. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address city country name assignment.
On 16/02/11 10:42, Henning Scholland wrote: -how do the different location-autofill options work? -what is the algorithm for getting the region for a place? -how are streets assigned to cities? -what is the purpose of the LocatorConfig.xml file? Don't forget the importanrs point: How to use it. :-) We could also consider having a different file format. It may be better to have a file for each country to make it easy for people to contribute for their country. I've nothing against XML, but for this kind of configuration a list of key=value pairs works just as well. eg: full-name = United Kingdom abbreviation = GBR etc... They can be combined during the build if that makes sense. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address city country name assignment.
It's amusing and not particularly surprising how, as soon as we have searchable maps, we discover the importance of having better addressing information about locations. So far a lot of a fundamental principles have been mentioned: * That using is_in information is easy, but not satisfactory, since it's often missing, inconsistent, poorly maintained and hard to use to infer a hierarchy of belonging (arbitrary bits of streets usually don't have it set, so how do you make a best guess of what nearby element should own it? * That boundary polygons are increasingly present on our map, that they can solve most of the problems of is_in, that they are already succeeding is_in for other address-sensitive applications in OSM, but that they are very hard to process as part of how mkgmap processes the map. I am convinced that is_in is never going to give us satisfactory results, that we cannot trust the values entered in that field by mappers and that, the more boundary polygons are used to solve other problems, the less is_in will even be maintained. I have not been entering is_in in my mapping for at least two years, at most I will correct entries by others. Mkgmap needs to, at those parts of the process where address hierarchy information is currently inferred, be capable of querying an external source to find the required information. Because at least some of my ideas for a possible source are a little cumbersome, it would probably be ideal if a number of options are permitted, rather like how drawing the sea is managed. One of the address lookup plugins would probably be the existing simple one based on is_in, for users who want to avoid extra prerequisites. So if that's what a simple, poorly-functioning address plugin looks like, what would the best one look like? Right now, the ultimate OSM geocoder is Nominatim. It is capable of consuming a place name or co-ordinate (of a road segment, say) and deducing an address hierarchy. It already uses the best clues available to do this - including both boundary polygons and is_in tags. And because an entire hierarchy is deduced, it offers us the flexibility to index locations under more than one hierarchy element, as many commercial Garmin maps seem to. For instance, my current location might reasonably be searched for under any of the following names in the city field: Dublin (city of which my location is a suburb) Dublin (historical county where I am located) Dublin 15 (postal district) Blanchardstown (Historical village and focus of modern suburb) and there are even sub-parts of Blanchardstown, typically corresponding to old rural townlands that might be searched for: Corduff, Ongar, Carpenterstown. Only the most disciplined maintainer of is_in will capture enough information to permit matching on all of these elements and there is no way sufficient consistency will exist. So a Nominatim lookup is the way to go, as we export all of the problems to an externally maintained tool. The snag: Even though Mapquest, who currently host the biggest public Nominatim instance, are very generous with the level of API lookups they allow there will be trouble if every mkgmap user performs thousands of Nominatim lookups when refreshing their Garmin maps. It will also be slow and bandwidth-intensive. This can be solved somewhat by having one's own instance of Nominatim, possibly containing only an interesting subset of the map. It would very likely prove worthwhile to define a cache file format into which to stuff those results of the query that mkgmap will require. If these cache files were maintained by country of bbox, they could be calculated centrally by people with sufficient hardware or expertise, then made available for download by normal users. This is a lot like what Steve suggests above, but without the expectation that mappers maintain the address file (because they just plain won't, and the required information is already available from Nominatim, so it would be a waste anyway). I'm interested in your comments on this. While to do what I describe certainly requires some hard work, it's all front-loaded, once we can find a working framework we never have to worry about it again. Well, not until Nominatim is superseded by an even more awesome geocoder. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - Umlaut problem
Am 16.02.2011 00:19, schrieb Steve Ratcliffe: just was wondering because v1850 was not crashing anymore. Oh OK. Well I believe that now it should work again in 1855. Yesss, Germany is working now. I see following regions: Be Belgique Berlin Bundesrepubblik Deutschalnd Cz Czech Republic Deutschland France Österreich Pl Poland Schweiz Could you add a mapping for Cz, Be and Pl to the LocatorConfig.xml ? How can I find the node with the typing error (Bundesrepubblik Deutschalnd) ? Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address city country name assignment.
On Feb 16, 2011, at 15:20, Dermot McNally wrote: On 16 February 2011 13:28, Robert Vollmert rvollmert-li...@gmx.net wrote: My suggestion would be to move region (country, city) detection into a preprocessing step, outside of mkgmap. That is, some other tool preprocesses and normalizes the osm data and assigns consistent is_in tags. Then mkgmap looks only at the is_in tags. That was actually my first thought on how to improve things. But the problem is that you would potentially be doing this: * Obtain hierarchy where the role of each element is known * Flatten this into an ordered list of elements, still respecting a hierarchy as best you can, but discarding the knowledge of roles * Bring this flattened version of the data into mkgmap and attempt to use the existing hints to extrapolate the knowledge of the roles that you only just threw away in the last step. So instead of writing is_in tags, write the actual data as relations? One relation per street, one relation per city, etc., with all streets as members in the corresponding city relation? Cheers Robert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address city country name assignment.
On 16 February 2011 14:40, Robert Vollmert rvollmert-li...@gmx.net wrote: So instead of writing is_in tags, write the actual data as relations? One relation per street, one relation per city, etc., with all streets as members in the corresponding city relation? I wasn't thinking of trying to force the address data into OSM format at all, but rather to store it away in a crude but persistent hash of a sort that mkgmap could learn to consult. Part of my reason for this is that I think the actual lookup of address data will be expensive, so you won't want to refresh these data as often as you will your planet extract - or at least, you'll want to confine you lookups to places that either aren't in your cache because they are new or that you have reason to suspect that a refresh is needed. If the hash is keyed on a combination of OSM ID and version, that could be the trigger for a fresh lookup from Nominatim or whatever service proves most useful. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter issue
On Sun, Nov 7, 2010 at 3:05 PM, Nakor nakor@gmail.com wrote: I was splitting the file from http://download.geofabrik.de/osm/north-america/us-west.osm.pbf and got the following error a couple times: Exception in thread worker-0 java.lang.StringIndexOutOfBoundsException: String index out of range: -2 at java.lang.String.getChars(String.java:860) at uk.me.parabola.splitter.OSMWriter.writeString(OSMWriter.java:203) at uk.me.parabola.splitter.OSMWriter.write(OSMWriter.java:98) at uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.processElement(SplitProcessor.java:294) at uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.run(SplitProcessor.java:327) at java.lang.Thread.run(Thread.java:636) Exception in thread worker-1 java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.getChars(String.java:860) at uk.me.parabola.splitter.OSMWriter.writeString(OSMWriter.java:203) at uk.me.parabola.splitter.OSMWriter.write(OSMWriter.java:105) at uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.processElement(SplitProcessor.java:294) at uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.run(SplitProcessor.java:327) at java.lang.Thread.run(Thread.java:636) Has anyone had a chance to look into this? I'm running into a similar issue when trying to split a .osm.pbf extract of the continental US generated by osmosis 0.38 from last week's planet file. I'm going to try and look into this a bit more but it might take a while as each run of the splitter takes 90+ minutes for me. I'm using splitter rev 161 from the crosby_integration branch. If I first convert pbf to osm using osmosis then split everything goes fine. -- Jeff Ollie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - Umlaut problem
Am 16.02.2011 14:01, schrieb Henning Scholland: How can I find the node with the typing error (Bundesrepubblik Deutschalnd) ? You can search with taginfo.openstreetmap.de. I found them and will fix them. Thanks for fixing. No I have to find out how to eliminate region 'Berlin'. ;) Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] java.lang.IllegalArgumentException
On Wed, Feb 16, Thorsten Kukuk wrote: Hi, with the mkgmap sr1846 I see now this java exception: Exception in thread main java.lang.IllegalArgumentException at java.nio.ByteBuffer.allocate(ByteBuffer.java:311) at uk.me.parabola.imgfmt.sys.Directory.sync(Directory.java:176) at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:230) at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:240) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:119) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:127) Ok, if I run the tile splitter with --max-nodes=70, I get this exception. But only for germany, haven't found any other country. With --max-nodes=100, it's working fine. Only problem: For some countrys, --max-nodes=100 is too much and mkgmap will abort ... Trying now IBM java 1.6.0, since I see heap corruption with SUN java sometimes which I never saw before when I used IBM java. Only disadvantage of IBM Java is, it is much slower (factor 6-10) than SUN java ... Between, using gmt to create a gmapsupp.img always works fine, even when mkgmap aborts with the above exception. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - Umlaut problem
Am 16.02.2011 17:22, schrieb Chris66: No I have to find out how to eliminate region 'Berlin'. ;) Node 262130957 fixed. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch: broken routing and sea generation
Am 16.02.2011 18:07, schrieb Carlos Dávila: Any attempt to compile map of Spain with index branch results in a map with all tiles with coast flooded and broken routing. For Germany both is ok. I had to manually correct the coast in one flooded tile. I'm using the default style. My options: --max-jobs=2 --latin1 --generate-sea=extend-sea-sectors,close-gaps=5000,floodblocker --description=OSMGERMANY --country-name=Deutschland --country-abbr=DEU --area-name=DEU --series-name=Germany --family-name=Germany --family-id=70 --product-id=1 --mapname=63240001 --delete-tags-file=..\delete.txt --route --net --remove-short-arcs --make-opposite-cycleways --add-pois-to-areas --link-pois-to-ways --index --location-autofill=1 --gmapsupp --tdbfile Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Generating sea
Hi Wanmil, No findings? The screenshots show clearly the difference between the maps created with mkgpmap-r1625 (generating sea is good, except the ghost rivers) and newer mkgmap-versions (incl. -r1846). Greetings Josef Am 10.02.2011 19:17, schrieb Josef Latt: Hi Wanmil, Did you download the screenshots? The missing north sea in sea_good.jpg is IMHO normal. It's outside the bounding polygon. Thanks for your answer. Josef Parameters for splitter and mkgmap: java -ea -Xmx2560M -jar ./splitter/splitter.jar --mapid=3001 --max-nodes=80 germany.osm java -ea -Xmx2560M -jar ./mkgmap-r1829/mkgmap.jar \ --description=OSM_DE \ --country-name=Deutschland --country-abbr=DE \ --name-tag-list=name:de,name,int_name \ --style-file=./style/ \ --generate-sea=extend-sea-sectors,close-gaps=5000 \ --family-id= --product-id=1 \ --series-name=OSM_Deutschland \ --area-name=Deutschland \ --overview-mapname=OSM_Deutschland \ --tdbfile \ --draw-priority=25 \ --latin1 \ --ignore-maxspeeds \ --ignore-turn-restrictions \ --no-poi-address \ --max-jobs=2 \ -c template.args .TYP Am 10.02.2011 18:45, schrieb WanMil: Josef, I downloaded the latest German extract from cloudmade.com. I splitted the extract using the default settings. In the map most of the North Sea is not created. Although this is not good I cannot reproduce your exact problem. Please provide the following information: * Splitter parameters * Your exact mkgmap parameters WanMil Hi, I use the German extract from cloudmade.com. With mkgmap-r1815, 1827, 1829 generating sea (--generate-sea=extend-sea-sectors,close-gaps=5000) is incomplete. See screenshot sea_bad.jpg. Using mkgmap-r1625 generating sea is o.k. but there are some ghost rivers. See screenshots sea_good.jpg and Ghostriver.jpg. Vou can download the screenshots as ZIP here: http://ge.tt/#70BMn5z Greetings Josef ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- PGP Schlüssel: 311D1055 http://keyserver.pgp.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Patch: Add Ireland to LocatorConfig.xml
I have applied your patch and added a very long list of other countries from the english wikipedia. It can be used as a starting point for patches to this file. WanMil It would be great if somebody could add the following patch to improve the address support in Ireland: Index: LocatorConfig.xml === --- LocatorConfig.xml (revision 1852) +++ LocatorConfig.xml (working copy) @@ -26,6 +26,11 @@ variantItaly/variant variantIT/variant /country + country name=Ireland abr=IRL regionOffset=3 + variantRepublic of Ireland/variant + variantÉire/variant + variantIE/variant + /country country name=France abr=FRA /country country name=España abr=ESP poiDispFlag=0xc Thanks, Dermot ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search and index.
It should be easier to maintain than the coastline data because the political (or adminstration??) bounding polygons should obey certain rules that could be checked automatically. Can you give an example? I don't see why it should be easier than coastline checking. 1) A bounding polygon ought to form a closed way. Coastlines seem to be composed of many open ways that happen to share end-points (more like roads). That latter fact makes it harder to check a coastline since a way flagged as coastline of France will at some point share endpoints with a way flagged as coastline of Spain, and that's true but not checkable automatically. 2) A bounding polygon's name ought to be unique within its own parent bounding-polygon. If for some reason you really want two bounding-polygons to be disjoint, but refer to the same logical place, you'd put them both in a relation. 3) There should not be an intersection of two bounding polygons at the same level. In other words, two towns can't intersect. 4) There are such things as cities that span multiple counties (like London, England for instance). There needs to be rules to allow that, maybe where the bounding-box for the majority of the county of Middlesex is required to be entirely outside the bounding box for London, but a second bounding-box (also flagged as 'county of Middlesex') is placed inside the bounding-box for London, but a member of a relation with the other Middlesex to prove that they are supposed to be the same. If the 'relation' was omitted, the auto-checkers would barf because you'd have two disjoint places called Middlesex inside the same parent bounding box (England). (You might choose to relax that rule if the two Middlesex bounding-boxes shared one or more periphery vectors, as they would here.) 5) The political:layer tags should increase in value as the bounding-boxes nest. In the unusual case of enclaves that I mentioned in my earlier post, you allow the layer value to break that rule (within the enclave the inherited knowledge of the parent bounding boxes is forgotten), but there has to be a tag to say political:enclave=yes or something to let it happen without the auto-checher barfing. 6) Er - there must be more! I don't understand, sorry. I think you assume that boundary information is stored as single polygon. This won't be accepted by the OSM community and is not how boundaries are tagged at the moment. Larger structures are realized as multipolygons. This makes sense because a national border is always a border of a county and a city etc. And editors like JOSM don't need to download the complete border of two countries just because you want to edit a small street crossing the border. Please have a look at the http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative and http://wiki.openstreetmap.org/wiki/Relation:boundary pages. Most of your ideas are already described there and can be found in the OSM data. As a result you have a bunch of lines and some polygons both for coastlines and for boundaries. You need to connect the open lines (boundaries use the multipolygon information to do this). In the end you have uncomplete data where you have to close some polygons automatically. There no substantial difference between coastline and boundary proessing. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-cycleways labels invisible
Op 16-2-2011 15:46, Felix Hartmann schreef:
On 16.02.2011 15:19, Minko wrote:
Can you give an example how this can be done in the style file:
A street with oneway=yes cycleway=opposite
-If the navigation is set to cars, routing is only possible in one way
-If navigation is set to bicycle, routing is possible in two ways
As far as I know this cannot be controlled in the style file. It is either
oneway=yes or oneway=no
Is bicycle:oneway=no (or yes) an option I can use in the lines style?
You introduce the rule
highway=* oneway=yes cycleway=opposite {set oneway=-1; set
access=no; set bicycle=yes} [0x?? road_speed=? road_class=? continue]
This rule of course has to be at the beginning. You do not need to care
about foot=yes as for pedestrian Garmin disrespects the oneway atribute.
Mind depending on the layout of your map - you may have to introduce
this rule several times each with according highway=residential and so
on. Everything else stays unchanged. You could also set to oneway=no...
It has the advantage that one can pick lower priority for going against
the general flow of traffic dependant on the highway type (or whatever
else). Basically this is exactly what the option is doing, with the
difference that you cannot influence road_class and road_speed )
Thank you, this is what I've been looking for... As soon as I have time
I'll try and use it!
J-.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon problem
WanMil schrieb am 08.01.2011 11:44: I have attached that patch to limit polygon creation to closed ways. It's untested and I assume there are some unwanted effects at tile borders. Please check and if you (and others) find it usefull it can be committed. Did anybody else try this patch? I haven't noticed any problems and would like to see this patch comitted. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Patch: Add Ireland to LocatorConfig.xml
On Feb 16, 2011, at 14:20, Henning Scholland wrote: I think it would be better, if this file would be external, so every user could edit this file. If you place LocatorConfig.xml in a sub-directory called resources in the same directory where you process the osm files (i.e., the directory where you call mkgmap from the command line), then this file will be used instead. That way, you can easily add your own country data without recompiling. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-cycleways labels invisible
Op 16-02-11 15:46, Felix Hartmann schreef:
highway=* oneway=yes cycleway=opposite {set oneway=-1; set
access=no; set bicycle=yes} [0x?? road_speed=? road_class=? continue]
What about the other oneway options? I.e. oneway could be 1, yes, -1
(and no, but that probably doesn't matter) as valid and/or legacy
options? I suppose for oneway=-1 one would need another {set oneway=1}
rule? (I'm not quite a rule specialist, as you may notice from my
ignorant questions).
I personally would hate to see the --make-cycleways option go; it's a
nice shortcut (hack if you like) for a pretty large style change.
Best regards,
Valentijn
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-cycleways labels invisible
On 16.02.2011 21:50, Minko wrote:
Thanks Felix,
But how about situations with highway=* oneway=-1?
Does this work too?
highway=* oneway=-1 cycleway=opposite {set oneway=yes; set
access=no; set bicycle=yes}
Yes of course. That's what you need to do (assuming that
cycleway=opposite really means that the way is against the flow of
traffic and not only on the opposite side...)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Patch: Add Ireland to LocatorConfig.xml
With 1860 everything seems to be assigned crazy for me. When compiling Austria from Geofabrik, and even setting the country name/abbrevation via commandline, Vienna ends up in Czech Rebublic, lotta cities in Germany and so on. Is there a problem with Umlauts? I have found very few cities in AUT - whereas for most other countries it shows the full name of Germany, Czech Republic and so on. Maybe problems with Umlauts in the list? I can only say, that 1858 was far superior in matching the right country AND city. I have again problems of finding a street when entering city name too (mind though that I have a peculiar setup in my style-file, in so far that I put in all cities with name:en in resolution 24 0x900 on top of the normal city for being able to find cities by their english name and local name). On 16.02.2011 20:16, WanMil wrote: I have applied your patch and added a very long list of other countries from the english wikipedia. It can be used as a starting point for patches to this file. WanMil It would be great if somebody could add the following patch to improve the address support in Ireland: Index: LocatorConfig.xml === --- LocatorConfig.xml(revision 1852) +++ LocatorConfig.xml(working copy) @@ -26,6 +26,11 @@ variantItaly/variant variantIT/variant /country +country name=Ireland abr=IRL regionOffset=3 +variantRepublic of Ireland/variant +variantÉire/variant +variantIE/variant +/country country name=France abr=FRA /country country name=España abr=ESP poiDispFlag=0xc Thanks, Dermot ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] search and address test (index-r1860)
Hi, Some test results using the index-r1860 for the Philippines using nuvi 1310. 1. Select country now has one option for the Philippines 2. Search by address by street name works. You can use both Spell City and Search All . One quirk, I noticed is that a street is assigned to a single place/city depending on the location of the place node. For example, Street x Y village, Z City can be found either in in X or Y and not both. The problem is that if there are many place=village or hamlet tags within a City, very few results will come out when using the actual city name. (I am aware that this is due to the use of the is_in tags and there are proposed ideas on using boundaries and relations and nominatim in the future) 3. City search now works. 4. Intersection works! However, it suffers the one-street-one-city-only issue as item 2. Moreover, when selecting Street1, you are given another window to select Street2. Pressing the Done button, you are given a list of street, but the provided street doesn't necessarily intersect with Street1. In some cases it can't find an intersection which I know has one but I think this is more of a data issue. 5. Search via substring works for POI search but not for City search. For example, with POI search, the word Pablo gives result like: San Pablo Pablo S. Pablo In the city search, you only get results when the query string is in the first word, like: Pablo Pablo, Laguna Overall, great work on the index! -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
