Re: [mkgmap-dev] LocatorConfig.xml and Spain
Do you use the "standard" mkgmap or do you use a build from the locator branch? WanMil >> Since I stopped using is_in and openGeoDb in my style files my >> problem on Belgium disappeared. > > I am sure those problematic country name variants are being read from > is_in tags. So ignoring is_in will make them disappear. But I do want to > use is_in, at least for now, until there is a better alternative. > > It is my understanding that the LocatorConfig.xml file should help to > normalize country names obtained from is_in tags. And something is > failing there. > > - Bartosz > ___ > 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
Re: [mkgmap-dev] [locator] Country specific rules
Hello,
Horb isn't complete in the tile. I created the tile also with osmosis with the
same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227).
Same behaviour.
But, I've created a place tag named Horb and now I can find all streets within
this tile. So the question is, is it needed that also the place-tag is within
the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and
helps to understand and fix this problem.
Without the place-tag in the tile:
http://snailrun.de/images/MapSearch/Ohne.png
With the place-tag in the tile:
http://snailrun.de/images/MapSearch/Mit.png
If you need further informations/tests just write me an email.
I'm german, sorry for my poor english, I try my best :)
Cheers
Martin
P.S.: Isn't it possible to attach pictures to the maillist?!
Am 06.05.2011 um 18:00 schrieb WanMil:
> Based on the logging and the current default style I would expect that
> you get a street with
> name = Schafblumenhalde
> country = Deutschland
> region = Landkreis Freudenstadt
> city = Horb am Neckar
>
> Can you please check if Horb is completely contained in one tile (63240403)?
>
> In that case I would assume that maybe this is an index problem. Maybe
> Steve is able to check that?!
>
> I will continue to add some more useful debug statements to the locator
> branch so that it is easier to track such things.
>
> WanMil
>
>> Sorry, me again.
>>
>> I used now the tile produced the splitter, which contains the the not found
>> streets of Horb. For e.g. I could find the Schafblumenhalde. With the
>> debug-logging (LocationHook = FINE) I find this in the logfile:
>>
>> 2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz:
>> Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to
>> [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk
>> Karlsruhe,mkgmap:admin_level6=Landkreis
>> Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am
>> Neckar,highway=residential,motorcar=destination]
>>
>>
>> Where is the problem?!
>> Are in the logfile are only not assignable streets logged?!
>>
>> Cheers
>> Martin
>>
>> Am 06.05.2011 um 09:44 schrieb Martin:
>>
>>> Good morning :)
>>>
>>> Both problems didn't come up, when I cut a small bounding box out of the
>>> main pbf-file with osmosis and create a map with just this one tile.
>>> Is it possible, that this problem comes from the splitter?!
>>>
>>> Cheers
>>> Martin
>>>
>>>
>>> Am 05.05.2011 um 17:44 schrieb Martin:
>>>
Hello,
this rules works very good. 2 strange things:
Sometimes Basecamp and the Oregon 450 has problems to find Streets
starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am
Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der Bleiche"
(http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a problem
with the Umlaute (äöü).
And the second thing:
I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted
into tiles with a 120 nodes. In Horb for example I can find the "Am
Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but not
the Lichtenbergstraße, Kirchstraße, Schafblumenhalde
(http://osm.org/go/0DhcL1dyJ-?way=22999129)
But when I cut out a bounding-box from the Germany.osm.pfb-file in the
size of Horb, I can find the all streets
Strange things...
Cheers
Martin
Am 04.05.2011 um 21:03 schrieb WanMil:
> I think only the city rules need to be tweaked in Germany:
>
> # Germany = DEU cities
> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set
> mkgmap:city='${mkgmap:admin_level8}' }
> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set
> mkgmap:city='${mkgmap:admin_level7}' }
> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set
> mkgmap:city='${mkgmap:admin_level6}' }
> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set
> mkgmap:city='${mkgmap:admin_level9}' }
> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set
> mkgmap:city='${mkgmap:admin_level10}' }
>
> First use admin_level=8 for city names. This covers all cities with a
> size up to 30. Bigger cities don't use admin_level=8 but
> admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the
> bigger city should be contained then in the admin_level 7 or 6.
>
> Please try it and give a feedback if that's ok. The upper rules are
> committed in r1937.
>
> Later on I will try your region settings.
>
> WanMil
>
>> In Germany we have the same mess...
>>
>> Actually I'm using this rules:
>>
>> mkgmap:country!=*& mkgmap:admin_level2=* { set
>> mkgmap:country='${mkgmap:
Re: [mkgmap-dev] [locator] Country specific rules
Can you please send your areas.list from the splitter? Then I can test
and debug myself.
The place-tag is evaluated only by the old locator. Which value do you
use for the parameter location-autofill? Please send also your complete
mkgmap commandlines with parameters.
WanMil
> Hello,
>
> Horb isn't complete in the tile. I created the tile also with osmosis with
> the same boundaries (top=48.735352 left=8.129883 bottom=48.295898
> right=8.657227). Same behaviour.
> But, I've created a place tag named Horb and now I can find all streets
> within this tile. So the question is, is it needed that also the place-tag is
> within the tile or maybe the boundfile? I've made 2 screenshots, I hope it
> works and helps to understand and fix this problem.
> Without the place-tag in the tile:
> http://snailrun.de/images/MapSearch/Ohne.png
> With the place-tag in the tile:
> http://snailrun.de/images/MapSearch/Mit.png
>
> If you need further informations/tests just write me an email.
> I'm german, sorry for my poor english, I try my best :)
>
> Cheers
> Martin
>
> P.S.: Isn't it possible to attach pictures to the maillist?!
>
>
>
>
>
>
> Am 06.05.2011 um 18:00 schrieb WanMil:
>
>> Based on the logging and the current default style I would expect that
>> you get a street with
>> name = Schafblumenhalde
>> country = Deutschland
>> region = Landkreis Freudenstadt
>> city = Horb am Neckar
>>
>> Can you please check if Horb is completely contained in one tile (63240403)?
>>
>> In that case I would assume that maybe this is an index problem. Maybe
>> Steve is able to check that?!
>>
>> I will continue to add some more useful debug statements to the locator
>> branch so that it is easier to track such things.
>>
>> WanMil
>>
>>> Sorry, me again.
>>>
>>> I used now the tile produced the splitter, which contains the the not found
>>> streets of Horb. For e.g. I could find the Schafblumenhalde. With the
>>> debug-logging (LocationHook = FINE) I find this in the logfile:
>>>
>>> 2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz:
>>> Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to
>>> [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk
>>> Karlsruhe,mkgmap:admin_level6=Landkreis
>>> Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am
>>> Neckar,highway=residential,motorcar=destination]
>>>
>>>
>>> Where is the problem?!
>>> Are in the logfile are only not assignable streets logged?!
>>>
>>> Cheers
>>> Martin
>>>
>>> Am 06.05.2011 um 09:44 schrieb Martin:
>>>
Good morning :)
Both problems didn't come up, when I cut a small bounding box out of the
main pbf-file with osmosis and create a map with just this one tile.
Is it possible, that this problem comes from the splitter?!
Cheers
Martin
Am 05.05.2011 um 17:44 schrieb Martin:
> Hello,
>
> this rules works very good. 2 strange things:
> Sometimes Basecamp and the Oregon 450 has problems to find Streets
> starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am
> Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der
> Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a
> problem with the Umlaute (äöü).
> And the second thing:
> I've created a german-map (http://snailrun.de/gmapsupp.img.zip), splitted
> into tiles with a 120 nodes. In Horb for example I can find the "Am
> Lochbrunnenstraße" (2 letters, space, more letters works here ?!?) but
> not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde
> (http://osm.org/go/0DhcL1dyJ-?way=22999129)
> But when I cut out a bounding-box from the Germany.osm.pfb-file in the
> size of Horb, I can find the all streets
> Strange things...
>
> Cheers
> Martin
>
>
>
>
> Am 04.05.2011 um 21:03 schrieb WanMil:
>
>> I think only the city rules need to be tweaked in Germany:
>>
>> # Germany = DEU cities
>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set
>> mkgmap:city='${mkgmap:admin_level8}' }
>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level7=* { set
>> mkgmap:city='${mkgmap:admin_level7}' }
>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level6=* { set
>> mkgmap:city='${mkgmap:admin_level6}' }
>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level9=* { set
>> mkgmap:city='${mkgmap:admin_level9}' }
>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level10=* { set
>> mkgmap:city='${mkgmap:admin_level10}' }
>>
>> First use admin_level=8 for city names. This covers all cities with a
>> size up to 30. Bigger cities don't use admin_level=8 but
>> admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the
>> bigger city should be contained t
Re: [mkgmap-dev] splitter PBF output support
I have downloaded the splitter.jar file and replaced it in the splitter r171 installation. I tried to split the geofabric europe dump. PBF files are created although I did not see any progress message about relations. The PBF files cannot be used by mkgmap so there seem to be a format problem: Error at line 1, col 1 Bad file format: europe\20110506\tiles\63240001.osm.pbf Error parsing file WanMil > I found the upload interface and placed the JAR here: > > http://files.mkgmap.org.uk/download/15/splitter.jar > > I've tested the NC maps today on a way to geocache and it worked ok so far. > > ___ > 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
Re: [mkgmap-dev] [locator] Country specific rules
Hello WanMil,
please find attached the area.list-file.
I use the following command:
java -Xmx1700M -Dlog.config=logging.properties -jar mkgmap-locator-r1937.jar
--boundsdirectory=bounds --latin1 --series-name=Germany --family-name=Germany
--remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines
--location-autofill=0 --country-name=Deutschland --country-abbr=DEU
--area-name=DEU --family-id=4 --product-id=45
--style-file=./master/basemap_style/ ./horb.osm ./master/basemap.TYP
Cheers
Martin
areas.list
Description: Binary data
Am 07.05.2011 um 13:45 schrieb WanMil:
> Can you please send your areas.list from the splitter? Then I can test
> and debug myself.
>
> The place-tag is evaluated only by the old locator. Which value do you
> use for the parameter location-autofill? Please send also your complete
> mkgmap commandlines with parameters.
>
> WanMil
>
>
>
>> Hello,
>>
>> Horb isn't complete in the tile. I created the tile also with osmosis with
>> the same boundaries (top=48.735352 left=8.129883 bottom=48.295898
>> right=8.657227). Same behaviour.
>> But, I've created a place tag named Horb and now I can find all streets
>> within this tile. So the question is, is it needed that also the place-tag
>> is within the tile or maybe the boundfile? I've made 2 screenshots, I hope
>> it works and helps to understand and fix this problem.
>> Without the place-tag in the tile:
>> http://snailrun.de/images/MapSearch/Ohne.png
>> With the place-tag in the tile:
>> http://snailrun.de/images/MapSearch/Mit.png
>>
>> If you need further informations/tests just write me an email.
>> I'm german, sorry for my poor english, I try my best :)
>>
>> Cheers
>> Martin
>>
>> P.S.: Isn't it possible to attach pictures to the maillist?!
>>
>>
>>
>>
>>
>>
>> Am 06.05.2011 um 18:00 schrieb WanMil:
>>
>>> Based on the logging and the current default style I would expect that
>>> you get a street with
>>> name = Schafblumenhalde
>>> country = Deutschland
>>> region = Landkreis Freudenstadt
>>> city = Horb am Neckar
>>>
>>> Can you please check if Horb is completely contained in one tile (63240403)?
>>>
>>> In that case I would assume that maybe this is an index problem. Maybe
>>> Steve is able to check that?!
>>>
>>> I will continue to add some more useful debug statements to the locator
>>> branch so that it is easier to track such things.
>>>
>>> WanMil
>>>
Sorry, me again.
I used now the tile produced the splitter, which contains the the not
found streets of Horb. For e.g. I could find the Schafblumenhalde. With
the debug-logging (LocationHook = FINE) I find this in the logfile:
2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz:
Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to
[motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk
Karlsruhe,mkgmap:admin_level6=Landkreis
Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am
Neckar,highway=residential,motorcar=destination]
Where is the problem?!
Are in the logfile are only not assignable streets logged?!
Cheers
Martin
Am 06.05.2011 um 09:44 schrieb Martin:
> Good morning :)
>
> Both problems didn't come up, when I cut a small bounding box out of the
> main pbf-file with osmosis and create a map with just this one tile.
> Is it possible, that this problem comes from the splitter?!
>
> Cheers
> Martin
>
>
> Am 05.05.2011 um 17:44 schrieb Martin:
>
>> Hello,
>>
>> this rules works very good. 2 strange things:
>> Sometimes Basecamp and the Oregon 450 has problems to find Streets
>> starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am
>> Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der
>> Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a
>> problem with the Umlaute (äöü).
>> And the second thing:
>> I've created a german-map (http://snailrun.de/gmapsupp.img.zip),
>> splitted into tiles with a 120 nodes. In Horb for example I can find
>> the "Am Lochbrunnenstraße" (2 letters, space, more letters works here
>> ?!?) but not the Lichtenbergstraße, Kirchstraße, Schafblumenhalde
>> (http://osm.org/go/0DhcL1dyJ-?way=22999129)
>> But when I cut out a bounding-box from the Germany.osm.pfb-file in the
>> size of Horb, I can find the all streets
>> Strange things...
>>
>> Cheers
>> Martin
>>
>>
>>
>>
>> Am 04.05.2011 um 21:03 schrieb WanMil:
>>
>>> I think only the city rules need to be tweaked in Germany:
>>>
>>> # Germany = DEU cities
>>> mkgmap:country=DEU& mkgmap:city!=*& mkgmap:admin_level8=* { set
>>> mkgmap:city='${mkgmap:admin_
Re: [mkgmap-dev] splitter PBF output support
Hi > I've decided to experiment with PBF support output in the splitter. I > got something working and I am testing it for the next week. Let me know > if someone else wants to give it a test. I don't have a place to put the > JAR but that can be fixed easily. Excellent! I see you've already made the jar available on files.mkgmap.org.uk and I've tried it out and it appears to work fine. One thing though is that the files in the template.args file are still written with the .osm.gz suffix, rather than the .osm.pbf suffix. Even if the code isn't fully ready, it would be good to send out a patch. Thanks Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error on MapSource with r1919
Hi
Sorry, the complete europe map still seems to trigger some limits.
It's again the mdr.img being>240MB. I uploaded the faulty file to the
mkgmap website. Here is the debug output ...
OK, thanks for that.
One more thought: the limit of 240 MB looks like the least siginifcant 4
bits of some limiting variable are masked out somehow,
256 - 16 = 240!?
Interesting...
Another thoght: Before r1919 the Europe map was working for me. What did
change with r1919 or later?
I started using the formula in:
http://en.wikipedia.org/wiki/Logical_Block_Addressing#CHS_conversion
instead of just guessing how it works.
Also there were attempts to increase the max size, followed by setting
the max size based on the actual size. Most of these changes have
mostly worked, but not for someone.
Is there a tool for download to analyse the imgfmt-structure?
For the disk header I use: http://sourceforge.net/projects/garmin-img/
The header is the first thing written so there is no need to let it
run to completion on a large file, nor worry if it crashes after
writing the *DSKIMG* file out. I use a patched version (patch attached
against 1.1).
For almost everything else there is a program in
http://svn.mkgmap.org.uk/display/trunk/ that will print the sections.
..Steve
Index: decode_header.cc
===
--- decode_header.cc (revision 2)
+++ decode_header.cc (working copy)
@@ -12,7 +12,8 @@
byte_t byte;
string str;
time_t ts;
- udword_t subfile_offset;
+ udword_t subfile_offset= 0x;
+ byte_t dir_start;
dec->set_outfile("DSKIMG", "header");
dec->print("XOR byte 0x%02x", img->xorbyte);
@@ -32,15 +33,15 @@
dec->print("%u sectors?", img->get_uword());
dec->print("%u heads?", img->get_uword());
+ dec->print("%u cyls", img->get_uword());
dec->print("???", img->get_word());
- dec->print("???", img->get_word());
dec->print("%s", img->get_string(25).c_str());
ts= img->get_date();
dec->print("Created %24.24s", ctime(&ts));
- dec->print("???", img->get_byte());
+ dec->print("Dir start?", (dir_start = img->get_byte()));
dec->print("%s", img->get_string(7).c_str());
@@ -72,8 +73,10 @@
dec->print("%u start-cylinder?", img->get_byte());
dec->print("%u system-type?", img->get_byte());
dec->print("%u end-head?", img->get_byte());
- dec->print("%u end-sector?", img->get_byte());
- dec->print("%u end-cylinder?", img->get_byte());
+ int s = img->get_byte() & 0xff;
+ dec->print("%u end-sector?", s & 0x3f);
+ int c = img->get_byte() & 0xff;
+ dec->print("%u end-cylinder?", ((s << 2) & 0x300) + c);
dec->print("%u rel-sectors?", img->get_udword());
dec->print("%u num-sectors?", img->get_udword());
dec->print(NULL, img->get_string(48).c_str());
@@ -82,26 +85,33 @@
dec->rawprint("*\n");
- img->seek(0x400);
+ img->seek(dir_start * 0x200);
- dec->print("???", img->get_byte());
- dec->print("???", img->get_string(11).c_str());
- dec->print("First subfile offset: 0x%06lx",
- subfile_offset= img->get_udword());
- dec->print("???", img->get_byte());
- dec->print("", img->get_string(15).c_str());
+ byte= img->get_byte();
+ if ( ! byte) {
+ img->seek(0x1000);
+ } else {
+ dec->print("???", img->get_byte());
+ dec->print("???", img->get_string(11).c_str());
+ dec->print("First subfile offset: 0x%06lx",
+ subfile_offset= img->get_udword());
+ dec->print("???", img->get_byte());
+ dec->print("", img->get_string(15).c_str());
- dec->print("Sequence block start", img->get_uword());
- dec->rawprint("*\n");
- dec->print("Sequence block end (block %u)",
- img->last_seq_block(0x600));
- if ( img->tell() != 0x600 ) {
- dec->print("Sequence block padding", img->get_uword());
+ dec->print("Sequence block start", img->get_uword());
dec->rawprint("*\n");
+
+ off_t end = (dir_start+1) * 0x200;
+ dec->print("Sequence block end (block %u)",
+ img->last_seq_block(end));
+ if ( img->tell() != end ) {
+ dec->print("Sequence block padding", img->get_uword());
+ dec->rawprint("*\n");
+ }
+
+ img->seek(end);
}
- img->seek(0x600);
-
dec->banner("Begin FAT");
while ( img->tell() < subfile_offset ) {
img_fat_block_t fblock;
@@ -146,6 +156,9 @@
img->seek(next_block);
}
fblock.offset= seq*img->block_size();
+
+ if ( ! fblock.offset ) valid= 0;
+
if ( ! part && valid ) {
class ImgFile *ifile;
class ImgSubfile *subfile;
@@ -154,6 +167,9 @@
fblock.offset);
img->fat.insert(make_pair(fblock.fullname, fblock));
+ if ( fblock.offset && fblock.offset < subfile_offset )
+subfile_offset= fblock.offset;
+
ifile= img->file_find(fblock.filename);
if ( ifile == NULL ) {
ifile= new ImgFile(img, fblock.filename);
@@ -161,8 +177,8 @@
ifile));
}
- ifile->subfile_add(fblock.extension, fblock.offset,
-fblock.size);
+ (void) ifile->subfile_add(fblock.extension,
+fblock.offset, fblock.size);
}
dec->rawprint("\n");
}
Index: decode_tre.cc
===
Re: [mkgmap-dev] Strange behaviour with a certain way type
Am 06.05.2011 18:13, schrieb Josef Latt: > Hi, > > I use 'continue' to show oneways and cycleways tagged on the road: > > highway=primary [0x02 level 5 continue] > highway=primary & oneway=yes [0x18 level 5 continue] > highway=primary & (cycleway=track | cycleway=lane | cycleway:left=* | > cycleway:right=*) [0x2e level 5] > > Ways which meet the first and the first+second argument are not colored. > Ways which meet the first and third argument are colored. Normally all > ways should be colored. > > If I change the arguments vice versa all ways are colored, but if I > point on the ways they were shown as cyleway or oneway and not as primary. > > This strange behavior concerns only this type of way (0x02). All the > other ways (have the same arguments) are colored as specified in the type. > > Bug or not? Forget it. The appearance on QLandkarteGT is quite good but not on the GPS. I go back using overlays. Greetings Josef -- 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] [locator] Country specific rules
Hello,
short question, because somebody wrote it also in the openstreetmap-forum.
In the default style seems to be an error.
mkgmap:postal_code!=* & mkgmap:postcode=* { set
mkgmap:postal_code='${mkgmap:postalcode}' }
should be
mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postcode
='${mkgmap:postalcode}' }
Cheers
Martin
Am 04.05.2011 um 19:02 schrieb WanMil:
> I want to start to collect and commit your country specific rules. I
> know some of you have already posted them on the list but I have lost
> track of it.
>
> So please post your country specific rules as an answer in this thread.
>
> WanMil
> ___
> 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
Re: [mkgmap-dev] splitter PBF output support
On 5/7/2011 7:52 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: > The PBF files cannot be used by mkgmap so there seem to be a format > problem: > Error at line 1, col 1 > Bad file format: europe\20110506\tiles\63240001.osm.pbf > Error parsing file What level of mkgmap are you using? That error seems to suggest it is trying to interpret the input as XML instead of PBF. I've made my tests with version r1867. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter PBF output support
On 5/7/2011 9:57 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: > I see you've already made the jar available on files.mkgmap.org.uk > and I've tried it out and it appears to work fine. One thing though is > that the files in the template.args file are still written with the > .osm.gz > suffix, rather than the .osm.pbf suffix. Fixed this on my working code. > Even if the code isn't fully ready, it would be good to send out a > patch. I am refactoring the code, so I will try to work on a patch on Monday or so. Not enough time this weekend. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] LocatorConfig.xml and Spain
> Do you use the "standard" mkgmap or do you use a build from the locator > branch? I built from trunk, not the locator branch. - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter PBF output support
> On 5/7/2011 7:52 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: >> The PBF files cannot be used by mkgmap so there seem to be a format >> problem: >> Error at line 1, col 1 >> Bad file format: europe\20110506\tiles\63240001.osm.pbf >> Error parsing file > What level of mkgmap are you using? That error seems to suggest it is > trying to interpret the input as XML instead of PBF. > > I've made my tests with version r1867. > The latest r1939. I think the relevant question is: which release of the protobuf.jar and the osmbin.jar do you use and which one should I use? WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [locator] bug, if streets were split
Hi, all streets, which were split in OSM-data get shown in search as often as parts exist in data. It would be great, if these separated streets would be shown only once, if parts have at least one common node. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] bug, if streets were split
And futhermore, if there is a city, which exist in 2 or more regions (e.g. Potsdam in Brandenburg and Schleswig-Holstein), only one (in Schleswig-Holstein) is on the Garmin device shown. Any idea how to avoid this?! In Basecamp all cities are shown. Cheers Martin Am 07.05.2011 um 20:25 schrieb Henning Scholland: > Hi, > all streets, which were split in OSM-data get shown in search as often as > parts exist in data. It would be great, if these separated streets would be > shown only once, if parts have at least one common node. > > Henning > ___ > 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
Re: [mkgmap-dev] [locator] Country specific rules
Martin, I cannot reproduce your problem but possibly that's because I misunderstood you. I splitted the geofabrik germany dump using your areas.list and then started mkgmap with your command line parameters. After that without any modification of the original OSM data I can find the street "Schafblumenhalde" (just search for the street name). The find dialog tells me that it is located in the town "Horb am Neckar" in region "Landkreis Freudenstadt" and country "DEU". So far so fine! But when I enter the city in the search dialog the street is not found any more. This should not be a problem of the locator branch but a more general problem with the index creation. Maybe Steve can have a look on it. WanMil > Hello WanMil, > > please find attached the area.list-file. > I use the following command: > java -Xmx1700M -Dlog.config=logging.properties -jar mkgmap-locator-r1937.jar > --boundsdirectory=bounds --latin1 --series-name=Germany --family-name=Germany > --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines > --location-autofill=0 --country-name=Deutschland --country-abbr=DEU > --area-name=DEU --family-id=4 --product-id=45 > --style-file=./master/basemap_style/ ./horb.osm ./master/basemap.TYP > > Cheers > Martin > > > > > > Am 07.05.2011 um 13:45 schrieb WanMil: > >> Can you please send your areas.list from the splitter? Then I can test >> and debug myself. >> >> The place-tag is evaluated only by the old locator. Which value do you >> use for the parameter location-autofill? Please send also your complete >> mkgmap commandlines with parameters. >> >> WanMil >> >> >> >>> Hello, >>> >>> Horb isn't complete in the tile. I created the tile also with osmosis with >>> the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 >>> right=8.657227). Same behaviour. >>> But, I've created a place tag named Horb and now I can find all streets >>> within this tile. So the question is, is it needed that also the place-tag >>> is within the tile or maybe the boundfile? I've made 2 screenshots, I hope >>> it works and helps to understand and fix this problem. >>> Without the place-tag in the tile: >>> http://snailrun.de/images/MapSearch/Ohne.png >>> With the place-tag in the tile: >>> http://snailrun.de/images/MapSearch/Mit.png >>> >>> If you need further informations/tests just write me an email. >>> I'm german, sorry for my poor english, I try my best :) >>> >>> Cheers >>> Martin >>> >>> P.S.: Isn't it possible to attach pictures to the maillist?! >>> >>> >>> >>> >>> >>> >>> Am 06.05.2011 um 18:00 schrieb WanMil: >>> Based on the logging and the current default style I would expect that you get a street with name = Schafblumenhalde country = Deutschland region = Landkreis Freudenstadt city = Horb am Neckar Can you please check if Horb is completely contained in one tile (63240403)? In that case I would assume that maybe this is an index problem. Maybe Steve is able to check that?! I will continue to add some more useful debug statements to the locator branch so that it is easier to track such things. WanMil > Sorry, me again. > > I used now the tile produced the splitter, which contains the the not > found streets of Horb. For e.g. I could find the Schafblumenhalde. With > the debug-logging (LocationHook = FINE) I find this in the logfile: > > 2011/05/06 09:55:17 FEIN (LocationHook): ./tiles_germany/63240403.osm.gz: > Added tag mkgmap:admin_level5 = Regierungsbezirk Karlsruhe to > [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk > Karlsruhe,mkgmap:admin_level6=Landkreis > Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am > Neckar,highway=residential,motorcar=destination] > > > Where is the problem?! > Are in the logfile are only not assignable streets logged?! > > Cheers > Martin > > Am 06.05.2011 um 09:44 schrieb Martin: > >> Good morning :) >> >> Both problems didn't come up, when I cut a small bounding box out of the >> main pbf-file with osmosis and create a map with just this one tile. >> Is it possible, that this problem comes from the splitter?! >> >> Cheers >> Martin >> >> >> Am 05.05.2011 um 17:44 schrieb Martin: >> >>> Hello, >>> >>> this rules works very good. 2 strange things: >>> Sometimes Basecamp and the Oregon 450 has problems to find Streets >>> starting with 2 letters, space, more letters (Am Anger, Am Lusbühl, Am >>> Hägle (http://osm.org/go/0DKQ69he@-?way=22999129)), but "Auf der >>> Bleiche" (http://osm.org/go/0DKQ43mIw--?way=22999129) works. It's not a >>> problem with the Umlaute (äöü). >>> And the second thing: >>> I've created a german-map (http://snailrun.de/gmapsupp.
Re: [mkgmap-dev] splitter PBF output support
> >> On 5/7/2011 7:52 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: >>> The PBF files cannot be used by mkgmap so there seem to be a format >>> problem: >>> Error at line 1, col 1 >>> Bad file format: europe\20110506\tiles\63240001.osm.pbf >>> Error parsing file >> What level of mkgmap are you using? That error seems to suggest it is >> trying to interpret the input as XML instead of PBF. >> >> I've made my tests with version r1867. >> > > The latest r1939. I think the relevant question is: which release of the > protobuf.jar and the osmbin.jar do you use and which one should I use? > > WanMil I was able to split germany with the new pfb support and the tiles were fine. I'll give it second try with the europe dump... WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
Have you searched for the street on a Garmin Device or in Mapsource/Basecamp? When I search it on my Oregon without a City, I find the street, but when I select this street, there is no location found (N --° E --°--). It seems, that the index-file creates a entry for this street, but then... something breaks. But when you copy the place-tag of horb into the tile, everythings works fine... Am 07.05.2011 um 21:13 schrieb WanMil: > Martin, > > I cannot reproduce your problem but possibly that's because I > misunderstood you. > I splitted the geofabrik germany dump using your areas.list and then > started mkgmap with your command line parameters. > > After that without any modification of the original OSM data I can find > the street "Schafblumenhalde" (just search for the street name). The > find dialog tells me that it is located in the town "Horb am Neckar" in > region "Landkreis Freudenstadt" and country "DEU". So far so fine! > > But when I enter the city in the search dialog the street is not found > any more. This should not be a problem of the locator branch but a more > general problem with the index creation. Maybe Steve can have a look on it. > > WanMil > > >> Hello WanMil, >> >> please find attached the area.list-file. >> I use the following command: >> java -Xmx1700M -Dlog.config=logging.properties -jar mkgmap-locator-r1937.jar >> --boundsdirectory=bounds --latin1 --series-name=Germany >> --family-name=Germany --remove-short-arcs --index --net --route --tdbfile >> --nsis --merge-lines --location-autofill=0 --country-name=Deutschland >> --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 >> --style-file=./master/basemap_style/ ./horb.osm ./master/basemap.TYP >> >> Cheers >> Martin >> >> >> >> >> >> Am 07.05.2011 um 13:45 schrieb WanMil: >> >>> Can you please send your areas.list from the splitter? Then I can test >>> and debug myself. >>> >>> The place-tag is evaluated only by the old locator. Which value do you >>> use for the parameter location-autofill? Please send also your complete >>> mkgmap commandlines with parameters. >>> >>> WanMil >>> >>> >>> Hello, Horb isn't complete in the tile. I created the tile also with osmosis with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 right=8.657227). Same behaviour. But, I've created a place tag named Horb and now I can find all streets within this tile. So the question is, is it needed that also the place-tag is within the tile or maybe the boundfile? I've made 2 screenshots, I hope it works and helps to understand and fix this problem. Without the place-tag in the tile: http://snailrun.de/images/MapSearch/Ohne.png With the place-tag in the tile: http://snailrun.de/images/MapSearch/Mit.png If you need further informations/tests just write me an email. I'm german, sorry for my poor english, I try my best :) Cheers Martin P.S.: Isn't it possible to attach pictures to the maillist?! Am 06.05.2011 um 18:00 schrieb WanMil: > Based on the logging and the current default style I would expect that > you get a street with > name = Schafblumenhalde > country = Deutschland > region = Landkreis Freudenstadt > city = Horb am Neckar > > Can you please check if Horb is completely contained in one tile > (63240403)? > > In that case I would assume that maybe this is an index problem. Maybe > Steve is able to check that?! > > I will continue to add some more useful debug statements to the locator > branch so that it is easier to track such things. > > WanMil > >> Sorry, me again. >> >> I used now the tile produced the splitter, which contains the the not >> found streets of Horb. For e.g. I could find the Schafblumenhalde. With >> the debug-logging (LocationHook = FINE) I find this in the logfile: >> >> 2011/05/06 09:55:17 FEIN (LocationHook): >> ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = >> Regierungsbezirk Karlsruhe to >> [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk >> Karlsruhe,mkgmap:admin_level6=Landkreis >> Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am >> Neckar,highway=residential,motorcar=destination] >> >> >> Where is the problem?! >> Are in the logfile are only not assignable streets logged?! >> >> Cheers >> Martin >> >> Am 06.05.2011 um 09:44 schrieb Martin: >> >>> Good morning :) >>> >>> Both problems didn't come up, when I cut a small bounding box out of >>> the main pbf-file with osmosis and create a map with just this one tile. >>> Is it possible, that this problem comes from the s
Re: [mkgmap-dev] splitter PBF output support
Pse give a the area-list if europe-split from geofabrik works for you. 2011/5/7 WanMil : >> >>> On 5/7/2011 7:52 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: The PBF files cannot be used by mkgmap so there seem to be a format problem: Error at line 1, col 1 Bad file format: europe\20110506\tiles\63240001.osm.pbf Error parsing file >>> What level of mkgmap are you using? That error seems to suggest it is >>> trying to interpret the input as XML instead of PBF. >>> >>> I've made my tests with version r1867. >>> >> >> The latest r1939. I think the relevant question is: which release of the >> protobuf.jar and the osmbin.jar do you use and which one should I use? >> >> WanMil > > I was able to split germany with the new pfb support and the tiles were > fine. I'll give it second try with the europe dump... > > WanMil > ___ > 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
Re: [mkgmap-dev] [locator] Country specific rules
I have used Mapsource. > Have you searched for the street on a Garmin Device or in Mapsource/Basecamp? > When I search it on my Oregon without a City, I find the street, but when I > select this street, there is no location found (N --° E --°--). > It seems, that the index-file creates a entry for this street, but then... > something breaks. > But when you copy the place-tag of horb into the tile, everythings works > fine... > > > Am 07.05.2011 um 21:13 schrieb WanMil: > >> Martin, >> >> I cannot reproduce your problem but possibly that's because I >> misunderstood you. >> I splitted the geofabrik germany dump using your areas.list and then >> started mkgmap with your command line parameters. >> >> After that without any modification of the original OSM data I can find >> the street "Schafblumenhalde" (just search for the street name). The >> find dialog tells me that it is located in the town "Horb am Neckar" in >> region "Landkreis Freudenstadt" and country "DEU". So far so fine! >> >> But when I enter the city in the search dialog the street is not found >> any more. This should not be a problem of the locator branch but a more >> general problem with the index creation. Maybe Steve can have a look on it. >> >> WanMil >> >> >>> Hello WanMil, >>> >>> please find attached the area.list-file. >>> I use the following command: >>> java -Xmx1700M -Dlog.config=logging.properties -jar >>> mkgmap-locator-r1937.jar --boundsdirectory=bounds --latin1 >>> --series-name=Germany --family-name=Germany --remove-short-arcs --index >>> --net --route --tdbfile --nsis --merge-lines --location-autofill=0 >>> --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 >>> --product-id=45 --style-file=./master/basemap_style/ ./horb.osm >>> ./master/basemap.TYP >>> >>> Cheers >>> Martin >>> >>> >>> >>> >>> >>> Am 07.05.2011 um 13:45 schrieb WanMil: >>> Can you please send your areas.list from the splitter? Then I can test and debug myself. The place-tag is evaluated only by the old locator. Which value do you use for the parameter location-autofill? Please send also your complete mkgmap commandlines with parameters. WanMil > Hello, > > Horb isn't complete in the tile. I created the tile also with osmosis > with the same boundaries (top=48.735352 left=8.129883 bottom=48.295898 > right=8.657227). Same behaviour. > But, I've created a place tag named Horb and now I can find all streets > within this tile. So the question is, is it needed that also the > place-tag is within the tile or maybe the boundfile? I've made 2 > screenshots, I hope it works and helps to understand and fix this problem. > Without the place-tag in the tile: > http://snailrun.de/images/MapSearch/Ohne.png > With the place-tag in the tile: > http://snailrun.de/images/MapSearch/Mit.png > > If you need further informations/tests just write me an email. > I'm german, sorry for my poor english, I try my best :) > > Cheers > Martin > > P.S.: Isn't it possible to attach pictures to the maillist?! > > > > > > > Am 06.05.2011 um 18:00 schrieb WanMil: > >> Based on the logging and the current default style I would expect that >> you get a street with >> name = Schafblumenhalde >> country = Deutschland >> region = Landkreis Freudenstadt >> city = Horb am Neckar >> >> Can you please check if Horb is completely contained in one tile >> (63240403)? >> >> In that case I would assume that maybe this is an index problem. Maybe >> Steve is able to check that?! >> >> I will continue to add some more useful debug statements to the locator >> branch so that it is easier to track such things. >> >> WanMil >> >>> Sorry, me again. >>> >>> I used now the tile produced the splitter, which contains the the not >>> found streets of Horb. For e.g. I could find the Schafblumenhalde. With >>> the debug-logging (LocationHook = FINE) I find this in the logfile: >>> >>> 2011/05/06 09:55:17 FEIN (LocationHook): >>> ./tiles_germany/63240403.osm.gz: Added tag mkgmap:admin_level5 = >>> Regierungsbezirk Karlsruhe to >>> [motorcycle=destination,access=destination,mkgmap:admin_level2=DEU,mkgmap:admin_level4=Baden-W�rttemberg,mkgmap:admin_level5=Regierungsbezirk >>> Karlsruhe,mkgmap:admin_level6=Landkreis >>> Freudenstadt,name=Schafblumenhalde,mkgmap:admin_level8=Horb am >>> Neckar,highway=residential,motorcar=destination] >>> >>> >>> Where is the problem?! >>> Are in the logfile are only not assignable streets logged?! >>> >>> Cheers >>> Martin >>> >>> Am 06.05.2011 um 09:44 schrieb Martin: >>> Good morning :) Both problems didn't come up, when I cut a small bounding box out of the main pb
Re: [mkgmap-dev] [locator] Country specific rules
El 06/05/11 17:41, Carlos Dávila escribió:
> El 05/05/11 00:50, navmaps escribió:
>>Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB
>>works best for the Garmin index. What you'll then see is that some OSM
>>boundaries need to be improved. But getting that done will create a
>>perfectly working index (except for adresses, but it's always nice to
>>have some wishes for the future :-) )
> Thank you for the information, I'll try your suggestion. Last week I
> spent quite a lot of time improving boundaries, so I hope I can
> currently get good results.
You were right, with the rules below I get rid of most wrong
State/Province in search dialog. I would keep is_in:city and addr:city
because there may be more than one city/village/hamlet within an
admin_level=8 boundary (municipalities) and they may help get the right
place.
mkgmap:country!=* & mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* & mkgmap:admin_level6=* { set
mkgmap:region='${mkgmap:admin_level6}' }
mkgmap:region!=* & mkgmap:admin_level5=* { set
mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:region!=* & mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* & mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' }
mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' }
mkgmap:city!=* & mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* & mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* & mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* & mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
El 07/05/11 18:28, Martin escribió:
> Hello,
>
> short question, because somebody wrote it also in the openstreetmap-forum.
> In the default style seems to be an error.
> mkgmap:postal_code!=*& mkgmap:postcode=* { set
> mkgmap:postal_code='${mkgmap:postalcode}' }
> should be
> mkgmap:postal_code!=*& mkgmap:postcode=* { set mkgmap:postcode
> ='${mkgmap:postalcode}' }
Wouldn't it be the right one?
mkgmap:postal_code!=* & mkgmap:postcode=* { set
mkgmap:postal_code='${mkgmap:postcode}' }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
Hi Carlos, I know this problem, because I live in a city where exactly
that is the case. The solution for that as has been applied in the
Netherlands and Belgium is to use a lower level boundary: in Belgium
admin_level 9 is used as the primary boundary, in the Netherlands
admin_level 10 is used as primary boundary (both before admin_level 8 is
used in the style files).
Cheers, Johan
On Sat, 07 May 2011 23:25:03 +0200, Carlos Dávila
wrote:
> El 06/05/11 17:41, Carlos Dávila escribió:
>> El 05/05/11 00:50, navmaps escribió:
>>>Hi Carlos, it's my experience that skipping is_in, addr: and
>>> openGeoDB
>>>works best for the Garmin index. What you'll then see is that
>>> some OSM
>>>boundaries need to be improved. But getting that done will
>>> create a
>>>perfectly working index (except for adresses, but it's always
>>> nice to
>>>have some wishes for the future :-) )
>> Thank you for the information, I'll try your suggestion. Last week I
>> spent quite a lot of time improving boundaries, so I hope I can
>> currently get good results.
> You were right, with the rules below I get rid of most wrong
> State/Province in search dialog. I would keep is_in:city and
> addr:city
> because there may be more than one city/village/hamlet within an
> admin_level=8 boundary (municipalities) and they may help get the
> right
> place.
>
> mkgmap:country!=* & mkgmap:admin_level2=* { set
> mkgmap:country='${mkgmap:admin_level2}' }
>
> mkgmap:region!=* & mkgmap:admin_level6=* { set
> mkgmap:region='${mkgmap:admin_level6}' }
> mkgmap:region!=* & mkgmap:admin_level5=* { set
> mkgmap:region='${mkgmap:admin_level5}' }
> mkgmap:region!=* & mkgmap:admin_level4=* { set
> mkgmap:region='${mkgmap:admin_level4}' }
> mkgmap:region!=* & mkgmap:admin_level3=* { set
> mkgmap:region='${mkgmap:admin_level3}' }
>
> mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' }
> mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' }
> mkgmap:city!=* & mkgmap:admin_level8=* { set
> mkgmap:city='${mkgmap:admin_level8}' }
> mkgmap:city!=* & mkgmap:admin_level7=* { set
> mkgmap:city='${mkgmap:admin_level7}' }
> mkgmap:city!=* & mkgmap:admin_level9=* { set
> mkgmap:city='${mkgmap:admin_level9}' }
> mkgmap:city!=* & mkgmap:admin_level10=* { set
> mkgmap:city='${mkgmap:admin_level10}' }
> ___
> 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
Re: [mkgmap-dev] [locator] Country specific rules
El 08/05/11 01:43, navmaps escribió:
> Hi Carlos, I know this problem, because I live in a city where exactly
> that is the case. The solution for that as has been applied in the
> Netherlands and Belgium is to use a lower level boundary: in Belgium
> admin_level 9 is used as the primary boundary, in the Netherlands
> admin_level 10 is used as primary boundary (both before admin_level 8 is
> used in the style files).
I had already thought about it, but according to wiki [1] both 9 and 10
levels are below the needed one. It would be necessary a new level
between 8 and 9 for that purpose. Perhaps a discussion on talk-es is to
be taken.
[1] http://wiki.openstreetmap.org/wiki/Key:admin_level#admin_level (spain)
> Cheers, Johan
>
> On Sat, 07 May 2011 23:25:03 +0200, Carlos Dávila
> wrote:
>> El 06/05/11 17:41, Carlos Dávila escribió:
>>> El 05/05/11 00:50, navmaps escribió:
Hi Carlos, it's my experience that skipping is_in, addr: and
openGeoDB
works best for the Garmin index. What you'll then see is that
some OSM
boundaries need to be improved. But getting that done will
create a
perfectly working index (except for adresses, but it's always
nice to
have some wishes for the future :-) )
>>> Thank you for the information, I'll try your suggestion. Last week I
>>> spent quite a lot of time improving boundaries, so I hope I can
>>> currently get good results.
>> You were right, with the rules below I get rid of most wrong
>> State/Province in search dialog. I would keep is_in:city and
>> addr:city
>> because there may be more than one city/village/hamlet within an
>> admin_level=8 boundary (municipalities) and they may help get the
>> right
>> place.
>>
>> mkgmap:country!=*& mkgmap:admin_level2=* { set
>> mkgmap:country='${mkgmap:admin_level2}' }
>>
>> mkgmap:region!=*& mkgmap:admin_level6=* { set
>> mkgmap:region='${mkgmap:admin_level6}' }
>> mkgmap:region!=*& mkgmap:admin_level5=* { set
>> mkgmap:region='${mkgmap:admin_level5}' }
>> mkgmap:region!=*& mkgmap:admin_level4=* { set
>> mkgmap:region='${mkgmap:admin_level4}' }
>> mkgmap:region!=*& mkgmap:admin_level3=* { set
>> mkgmap:region='${mkgmap:admin_level3}' }
>>
>> mkgmap:city!=*& is_in:city=* { set mkgmap:city='${is_in:city}' }
>> mkgmap:city!=*& addr:city=* { set mkgmap:city='${addr:city}' }
>> mkgmap:city!=*& mkgmap:admin_level8=* { set
>> mkgmap:city='${mkgmap:admin_level8}' }
>> mkgmap:city!=*& mkgmap:admin_level7=* { set
>> mkgmap:city='${mkgmap:admin_level7}' }
>> mkgmap:city!=*& mkgmap:admin_level9=* { set
>> mkgmap:city='${mkgmap:admin_level9}' }
>> mkgmap:city!=*& mkgmap:admin_level10=* { set
>> mkgmap:city='${mkgmap:admin_level10}' }
>> ___
>> 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
--
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx,
.ppt, .pptx, .mdb, mdbx
Instale OpenOffice desde http://es.openoffice.org/programa/index.html
OpenOffice es libre: se puede copiar, modificar y redistribuir libremente.
Gratis y totalmente legal.
OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas
versiones.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
