Re: [mkgmap-dev] mkgmap:fast_road
Gerd and Andrzej, I have doubt if the main question here is the tag not be supported by the OSM database, but rather the way mkgmap interprets: internally in the java code or "externally" through rules/syntax in style script. I also don't think the fact that it is not handled internally by the mkgmap's java code gives the tag a temporary status to be prefixed by "tmp". In my opinion, both rules handled internally in the java code or in the styles can be permanent and definitive. Therefore, if the tags prefixed by "mkgmap:" are those handled internally in the java code, then I propose simply remove any prefix from this tag, leaving only "fast_road". Regards, Alexandre 2017-08-18 3:52 GMT-03:00 Gerd Petermann : > Hi Andrzej, > > I agree that the mkgmap prefix was not the best choice here. > There are a few more tags created in the default style which are not > expected in the OSM database and which are not evaluated in the java code: > cityxxx > dest_hint > exit_hint > maybe more ? > > I thought about a prefix like tmp: for them but I also like style: . > > Comments? > Gerd > > > Von: mkgmap-dev im Auftrag von > Andrzej Popowski > Gesendet: Freitag, 18. August 2017 00:37:31 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] mkgmap:fast_road > > Hi, > > the name "mkgmap:fast_road" could be a bit misleading, but it follows > kind of convention, that I have used in my styles for a long time. Now > reading this thread, I think it could be better to use something like > "style:fast_road" for local variables created in a style. > > -- > Best regards, > Andrzej > > > ___ > 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap:fast_road
Hi Gerd,
I read what Andrzej wrote, but it only made sense for me when I found the
rest of the changes in the "lines" file. I had only seen the line
highway=* & mkgmap:fast_road!=* & (int_ref=* | network=e-road | network=AH
| network=TAH | network=US:I | network=US:US) {add mkgmap:fast_road=yes}
That added "mkgmap: fast_road = yes" and I did not understand the behavior.
Then I found the following entries in the "lines" file using the recently
added fast_road tag and everything made sense:
Junction = roundabout & (highway = primary | highway = primary_link) &
mkgmap: fast_road = yes [0x0c road_class = 4 road_speed = 2 resolution 24
continue]
Junction = roundabout & (highway = primary | highway = primary_link) &
mkgmap: fast_road = yes [0x10802 resolution 19]
Junction = roundabout & (highway = secondary | highway = secondary_link) &
mkgmap: fast_road = yes [0x0c road_class = 3 road_speed = 2 resolution 24
continue]
Junction = roundabout & (highway = secondary | highway = secondary_link) &
mkgmap: fast_road = yes [0x10803 resolution 20]
Thanks.
Regards,
Alexandre
2017-08-17 14:33 GMT-03:00 Gerd Petermann :
> Hi Alexandre,
>
> please read the comment in the link, the tag is used to improve long
> distance routing.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag von
> Alexandre Loss
> Gesendet: Donnerstag, 17. August 2017 19:31:16
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap:fast_road
>
> Hi Gerd,
>
> So, this tag doesn't have any effect for now, right?
>
> But, what is its future purpose? Would perhaps increase the class of the
> highways set with this tag?
>
> Thanks.
>
> Alexandre
>
> 2017-08-17 14:24 GMT-03:00 Gerd Petermann <mailto:gpetermann_muenc...@hotmail.com>>:
> Hi Alexandre,
>
> see http://gis.19327.n8.nabble.com/Commit-r3979-routing-
> patch-by-Andrzej-Popowski-slightly-modified-tp5900321.html
>
> I did not document the tag because it is not evaluated in the java code.
>
> Gerd
>
> Von: mkgmap-dev mailto:mkgmap-
> dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Alexandre Loss <
> alexandre.l...@gmail.com<mailto:alexandre.l...@gmail.com>>
> Gesendet: Donnerstag, 17. August 2017 19:09:17
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] mkgmap:fast_road
>
> Hi Gerd,
>
> Sorry If I missed the discussion about the tag "mkgmap: fast_road", but I
> did not see anything about this in the manual and neither searching the net.
>
> I became aware of this tag by downloading the mkgmap 3993 and analyzing
> the changes in the standard "line" and "relation" files.
>
> What is the pratical result/behavior of this tag in the routing?
>
> Thanks.
>
> Alexandre Loss
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk<mailto: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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap:fast_road
Hi Gerd, So, this tag doesn't have any effect for now, right? But, what is its future purpose? Would perhaps increase the class of the highways set with this tag? Thanks. Alexandre 2017-08-17 14:24 GMT-03:00 Gerd Petermann : > Hi Alexandre, > > see http://gis.19327.n8.nabble.com/Commit-r3979-routing- > patch-by-Andrzej-Popowski-slightly-modified-tp5900321.html > > I did not document the tag because it is not evaluated in the java code. > > Gerd > > Von: mkgmap-dev im Auftrag von > Alexandre Loss > Gesendet: Donnerstag, 17. August 2017 19:09:17 > An: Development list for mkgmap > Betreff: [mkgmap-dev] mkgmap:fast_road > > Hi Gerd, > > Sorry If I missed the discussion about the tag "mkgmap: fast_road", but I > did not see anything about this in the manual and neither searching the net. > > I became aware of this tag by downloading the mkgmap 3993 and analyzing > the changes in the standard "line" and "relation" files. > > What is the pratical result/behavior of this tag in the routing? > > Thanks. > > Alexandre Loss > ___ > 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] mkgmap:fast_road
Hi Gerd, Sorry If I missed the discussion about the tag "mkgmap: fast_road", but I did not see anything about this in the manual and neither searching the net. I became aware of this tag by downloading the mkgmap 3993 and analyzing the changes in the standard "line" and "relation" files. What is the pratical result/behavior of this tag in the routing? Thanks. Alexandre Loss ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Is index size really reduced with --road-name-config option?
Hi Carlos, I confirm the reduction in the index size of our maps and in fact we are using in combination with --split-name-index Regards, Alexandre 2017-06-23 13:28 GMT-03:00 Gerd Petermann : > Hi Carlos, > I would only expect a reduction in combination with --split-name-index > Ciao Gerd > > Carlos Dávila schrieb ---- > > Alexandre Loss reported a reduction of 27 MB in index size for Brazil, > but I don't see that effect. I did some test with Spain map, with the > following results: > custom style, no road-name-config: 39.501.824 B > custom style+road-name-config: 39.567.360 B > default style, no road-name-config: 38.633.472 B > default style+road-name-config: 38.682.624 B > As you can see, index is even slightly larger with road-name-config. > Maybe I missed something. > My command: java -Xmx2000m -ea -jar mkgmap.jar --bounds=bounds.zip > --precomp-sea=sea.zip --route --latin1 --code-page=1252 > --country-name=ESPAÑA --country-abbr=ESP --area-name=España > --family-name="OpenStreetMap España" --family-id=114 --product-id=1 > --series-name="OSM-España" --index --process-destination --process-exits > --housenumbers --reduce-point-density=4 --add-pois-to-areas > --link-pois-to-ways --location-autofill=is_in,nearest --drive-on=right > --check-roundabouts --license-file=license_ODbL.txt > --copyright-message="OpenStreetMap contributors, ODbL. See: > http://www.openstreetmap.org/copyright"; -c spain.args > ___ > 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r3971: - roadNameConfig_v1.patch by Carlos Davida which adds more countries and languages
I agree!
2017-06-14 15:58 GMT-03:00 Carlos Dávila :
> Yes, I know. I just wanted to mention there are a few occurrences of them
> in Portuguese. I don't think including them will cause too much processing
> time penalty.
>
> El 14/06/17 a las 20:17, Alexandre Loss escribió:
>
>> Hi Carlos,
>> These are most common prefixes for Spanish language.
>> [],
>> Loss
>>
>> 2017-06-14 15:14 GMT-03:00 Carlos Dávila > <mailto:cdavi...@orangecorreo.es>>:
>>
>> Working on "Avenida" prefix (shared between Spanish and
>> Portuguese) I also found a few cases with "de las", "del , "d'",
>> "el ", "la " in Brazil and/or Portugal
>>
>> El 14/06/17 a las 20:03, Alexandre Loss escribió:
>>
>> Hi Carlos,
>>
>> In our project here in Brazil (tracksource.org.br
>> <http://tracksource.org.br> <http://tracksource.org.br>), we
>> started using this new feature with the following configuration:
>> # portuguese
>> prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco",
>> "Praça", "Rotatória", "Via", "Viela", "Estrada"
>> prefix2:pt = "da ", "do ", "de ", "das ", "dos ", "para "
>>
>> Gradually and with more tests we should consider the expansion
>> to other prefixes.
>> With this configuration we obtained a 27 MB reduction in the
>> size of our index file (whole Brazil).
>>
>> Regards,
>>
>> Loss
>>
>> 2017-06-14 14:38 GMT-03:00 Alexandre Folle de Menezes
>> mailto:afmlis...@terra.com.br>
>> <mailto:afmlis...@terra.com.br <mailto:afmlis...@terra.com.br>>>:
>>
>>
>> Fine then, my mistake. But I still would like to have the
>> title
>> corrected ("Portug_u_ese") and "Beco" added.
>>
>> Also, I am not sure if "Estrada" and "Rodovia" should be added
>> (both mean "Road"). I am currently using both on my maps, but
>> they since are not common in urban areas, I am not sure
>> what the
>> convention is.
>>
>> Best regards,
>>
>> Alexandre
>>
>> Em 14/06/2017 13:24, Gerd Petermann escreveu:
>>
>> Hi,
>> I think with the current code the order really doesn't
>> matter.
>> That is also mentioned in the comments.
>> Ciao Gerd
>>
>> Alexandre Folle de Menezes schrieb
>>
>> Hola Carlos,
>>
>> I see that you are listing the prefixes in alphabetic
>> order. I
>> believe it would be way more efficient to put the most
>> common
>> prefixes first.
>>
>> For Portuguese, that would be (as I suggested in a
>> previous message):
>>
>> -# portugese
>> -prefix1:pt = "Rua", "Avenida", "Travessa"
>> -prefix2:pt = "da ", "do ", "de ", "das ", "dos "
>> +# portuguese
>> +prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda",
>> "Beco"
>> +prefix2:pt = "da ", "do ", "das ", "dos ", "de ", "d'"
>> Saludos,
>>
>> Alexandre
>>
>> Em 13/06/2017 18:19, Carlos Dávila escreveu:
>>
>> El 12/06/17 a las 06:22, svn commit escribió:
>>
>> Version mkgmap-r3971 was committed by gerd on
>> Mon, 12 Jun 2017
>>
>> - roadNameConfig_v1.patch by Carlos Davida
>> which adds more
>> countries and languages
>> - Improve comments
>>
>> Attached is version 2 of roadNameConfig.patch
>> I'm working in the completion of roadNameConfig
>> file. I think if
>> I could somehow get a file with the list of road
>> names in a map
>> I could advance faster in this task. Is there any
>> tool to get it
>> in the display project?
>>
>>
>>
>>
> ___
> 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] Commit r3971: - roadNameConfig_v1.patch by Carlos Davida which adds more countries and languages
Hi Carlos,
These are most common prefixes for Spanish language.
[],
Loss
2017-06-14 15:14 GMT-03:00 Carlos Dávila :
> Working on "Avenida" prefix (shared between Spanish and Portuguese) I also
> found a few cases with "de las", "del , "d'", "el ", "la " in Brazil and/or
> Portugal
>
> El 14/06/17 a las 20:03, Alexandre Loss escribió:
>
>> Hi Carlos,
>>
>> In our project here in Brazil (tracksource.org.br <
>> http://tracksource.org.br>), we started using this new feature with the
>> following configuration:
>> # portuguese
>> prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco", "Praça",
>> "Rotatória", "Via", "Viela", "Estrada"
>> prefix2:pt = "da ", "do ", "de ", "das ", "dos ", "para "
>>
>> Gradually and with more tests we should consider the expansion to other
>> prefixes.
>> With this configuration we obtained a 27 MB reduction in the size of our
>> index file (whole Brazil).
>>
>> Regards,
>>
>> Loss
>>
>> 2017-06-14 14:38 GMT-03:00 Alexandre Folle de Menezes <
>> afmlis...@terra.com.br <mailto:afmlis...@terra.com.br>>:
>>
>> Fine then, my mistake. But I still would like to have the title
>> corrected ("Portug_u_ese") and "Beco" added.
>>
>> Also, I am not sure if "Estrada" and "Rodovia" should be added
>> (both mean "Road"). I am currently using both on my maps, but
>> they since are not common in urban areas, I am not sure what the
>> convention is.
>>
>> Best regards,
>>
>> Alexandre
>>
>> Em 14/06/2017 13:24, Gerd Petermann escreveu:
>>
>>> Hi,
>>> I think with the current code the order really doesn't matter.
>>> That is also mentioned in the comments.
>>> Ciao Gerd
>>>
>>> Alexandre Folle de Menezes schrieb
>>>
>>> Hola Carlos,
>>>
>>> I see that you are listing the prefixes in alphabetic order. I
>>> believe it would be way more efficient to put the most common
>>> prefixes first.
>>>
>>> For Portuguese, that would be (as I suggested in a previous message):
>>>
>>> -# portugese
>>> -prefix1:pt = "Rua", "Avenida", "Travessa"
>>> -prefix2:pt = "da ", "do ", "de ", "das ", "dos "
>>> +# portuguese
>>> +prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco"
>>> +prefix2:pt = "da ", "do ", "das ", "dos ", "de ", "d'"
>>> Saludos,
>>>
>>> Alexandre
>>>
>>> Em 13/06/2017 18:19, Carlos Dávila escreveu:
>>>
>>>> El 12/06/17 a las 06:22, svn commit escribió:
>>>>
>>>>> Version mkgmap-r3971 was committed by gerd on Mon, 12 Jun 2017
>>>>>
>>>>> - roadNameConfig_v1.patch by Carlos Davida which adds more
>>>>> countries and languages
>>>>> - Improve comments
>>>>>
>>>>> Attached is version 2 of roadNameConfig.patch
>>>> I'm working in the completion of roadNameConfig file. I think if
>>>> I could somehow get a file with the list of road names in a map
>>>> I could advance faster in this task. Is there any tool to get it
>>>> in the display project?
>>>>
>>>
>>
> ___
> 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] Commit r3971: - roadNameConfig_v1.patch by Carlos Davida which adds more countries and languages
Hi Carlos,
In our project here in Brazil (tracksource.org.br), we started using this
new feature with the following configuration:
# portuguese
prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco", "Praça",
"Rotatória", "Via", "Viela", "Estrada"
prefix2:pt = "da ", "do ", "de ", "das ", "dos ", "para "
Gradually and with more tests we should consider the expansion to other
prefixes.
With this configuration we obtained a 27 MB reduction in the size of our
index file (whole Brazil).
Regards,
Loss
2017-06-14 14:38 GMT-03:00 Alexandre Folle de Menezes <
afmlis...@terra.com.br>:
> Fine then, my mistake. But I still would like to have the title corrected
> ("Portug*u*ese") and "Beco" added.
>
> Also, I am not sure if "Estrada" and "Rodovia" should be added (both mean
> "Road"). I am currently using both on my maps, but they since are not
> common in urban areas, I am not sure what the convention is.
>
> Best regards,
>
> Alexandre
> Em 14/06/2017 13:24, Gerd Petermann escreveu:
>
> Hi,
> I think with the current code the order really doesn't matter. That is
> also mentioned in the comments.
> Ciao Gerd
>
> Alexandre Folle de Menezes schrieb
>
> Hola Carlos,
>
> I see that you are listing the prefixes in alphabetic order. I believe it
> would be way more efficient to put the most common prefixes first.
>
> For Portuguese, that would be (as I suggested in a previous message):
>
> -# portugese
> -prefix1:pt = "Rua", "Avenida", "Travessa"
> -prefix2:pt = "da ", "do ", "de ", "das ", "dos "
> +# portuguese
> +prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco"
> +prefix2:pt = "da ", "do ", "das ", "dos ", "de ", "d'"
>
> Saludos,
>
> Alexandre
>
> Em 13/06/2017 18:19, Carlos Dávila escreveu:
>
> El 12/06/17 a las 06:22, svn commit escribió:
>
> Version mkgmap-r3971 was committed by gerd on Mon, 12 Jun 2017
>
> - roadNameConfig_v1.patch by Carlos Davida which adds more countries and
> languages
> - Improve comments
>
> Attached is version 2 of roadNameConfig.patch
> I'm working in the completion of roadNameConfig file. I think if I could
> somehow get a file with the list of road names in a map I could advance
> faster in this task. Is there any tool to get it in the display project?
>
>
> ___
> mkgmap-dev mailing
> listmkgmap-...@lists.mkgmap.org.ukhttp://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
> ___
> mkgmap-dev mailing
> listmkgmap-...@lists.mkgmap.org.ukhttp://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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with roadNameConfig file
Confirmed it's fixed now in 3972! Thanks! 2017-06-12 14:50 GMT-03:00 Carlos Dávila : > Thanks for the quick fix. It works fine now. > > El 12/06/17 a las 19:15, Gerd Petermann escribió: > > Hi Carlos, >> >> thanks for reporting. I've fixed a stupid error in r3972, I think this >> should fix your problem. >> >> Gerd >> >> Von: mkgmap-dev im Auftrag von >> Carlos Dávila >> Gesendet: Montag, 12. Juni 2017 18:54:17 >> An: Development list for mkgmap >> Betreff: [mkgmap-dev] Problem with roadNameConfig file >> >> Hi Gerd >> It seems only first entry in prefix1 line is evaluated. I have a test >> file with >> road1: highway=primary, name=Calle las Grullas >> road2: highway=primary, name=Avenida Virgen de los Pastores >> If roadNameConfig file contains the line >> prefix1:es = "Calle", "Avenida" >> I can search for "Las Grullas" and "Grullas" and not for "Calle..." as >> expected. I can also search for "Avenida Virgen...", but not for >> "Virgen..." >> If roadNameConfig contains >> prefix1:es = "Avenida", "Calle" >> then I can search for "Virgen..." and "Calle las Grullas" but not for >> "Avenida Virgen..." nor "Grullas". >> ___ >> >> > ___ > 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] Problem with roadNameConfig file
Hi Gerd, I confirm the same behavior reported by Carlos in my tests here. Regards, Alexandre 2017-06-12 14:15 GMT-03:00 Gerd Petermann : > Hi Carlos, > > thanks for reporting. I've fixed a stupid error in r3972, I think this > should fix your problem. > > Gerd > > Von: mkgmap-dev im Auftrag von > Carlos Dávila > Gesendet: Montag, 12. Juni 2017 18:54:17 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Problem with roadNameConfig file > > Hi Gerd > It seems only first entry in prefix1 line is evaluated. I have a test > file with > road1: highway=primary, name=Calle las Grullas > road2: highway=primary, name=Avenida Virgen de los Pastores > If roadNameConfig file contains the line > prefix1:es = "Calle", "Avenida" > I can search for "Las Grullas" and "Grullas" and not for "Calle..." as > expected. I can also search for "Avenida Virgen...", but not for > "Virgen..." > If roadNameConfig contains > prefix1:es = "Avenida", "Calle" > then I can search for "Virgen..." and "Calle las Grullas" but not for > "Avenida Virgen..." nor "Grullas". > ___ > 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Doubt when using "road-name-config"
Hi Gerd, "the prefixes are only removed when you zoom out and the full name would be too long to be displayed." That's it! It's working and I just noticed when I zoomed out. And it makes perfect sense that it works this way. Regarding the LocatorConfig.xml file, the current default configuration meets my need since I use "BRA". However, I suggest including the variation in Portuguese: Brasil Many thanks for the support! Best regards, Alexandre 2017-06-12 1:04 GMT-03:00 Gerd Petermann : > Hi Alexandre, > > the prefixes are only removed when you zoom out and the full name would be > too long > to be displayed. Sometimes MapSource decides to render the shortened name > instead, > sometimes it is not rendered. I think this depends on the "level of > details" setting. > > The file LocatorConfig.xml is shipped with the mkgmap.jar and contains > other country specific > information, e.g. > > BR > BRA > Brazil > > > Follow the link which I pasted to browse the file content or extract it > from the jar > mkgmap.jar\LocatorConfig.xml > I think you can use a modified version of the file when you place it into > a directory \resources > in the working directory of mkgmap. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Alexandre Loss > Gesendet: Sonntag, 11. Juni 2017 23:25:39 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Doubt when using "road-name-config" > > Thank you Carlos and Gerd by your answers. > > In fact, I don't use the default style, but each way is tagged with > "mkgmap:country=BRA", as you can see in a partial sample extracted from a > mkgmap execution with echotags: > > Way 6761 [addr:city=BRUMADINHO, addr:country=BRA, addr:state=MG, > highway=residential, mkgmap:city=BRUMADINHO, mkgmap:country=BRA, > mkgmap:label:1=RUA DAS ROSAS, mkgmap:region=MG, mkgmap:street=RUA DAS > ROSAS, name=RUA DAS ROSAS] > Way 13983 [addr:city=BRUMADINHO, addr:country=BRA, addr:state=MG, > highway=residential, mkgmap:city=BRUMADINHO, mkgmap:country=BRA, > mkgmap:label:1=RUA RUBI, mkgmap:region=MG, mkgmap:street=RUA RUBI, name=RUA > RUBI] > > > This is may roadNameConfig.txt file in this test: > > ## > # Section 1 > # prefix1: list of 1st words > # prefix2: further words to combine with each prefix1 word, > separated with a blank > # suffix: gives list of suffix words > > # portugese > prefix1:pt = "Rua", "Avenida", "Travessa" > prefix2:pt = "da ", "do ", "de ", "das ", "dos " > > ## > # Section 2 > # Map 3 letter ISO country codes to list of used languages for road names. > > lang:BRA = pt > lang:PRT = pt > > And in MapSource I'm still viewing the ways with full name prefixed bye > "Rua" and "Rua das ": > > [Imagem inline 1] > > > What can I'm doing wrong? > > And Gerd, in your last email you quoted the "LocatorConfig.xml" file. What > file is this and where can I find it? > > Thanks. > > Alexandre > > > 2017-06-11 12:00 GMT-03:00 Gerd Petermann <mailto:gpetermann_muenc...@hotmail.com>>: > Hi, > > Carlos is right for the default style. If you use a very different style, > make sure that mkgmap:country contains the > 3 letter iso code for the country. See also the file LocatorConfig.xml. > I'll try to make that clearer in the coments > in roadNameConfig.txt. > > https://github.com/openstreetmap/mkgmap/tree/master/resources > > Gerd > > Von: mkgmap-dev mailto:mkgmap- > dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Carlos Dávila < > cdavi...@orangecorreo.es<mailto:cdavi...@orangecorreo.es>> > Gesendet: Sonntag, 11. Juni 2017 15:32 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Doubt when using "road-name-config" > > El 11/06/17 a las 14:42, Alexandre Loss escribió: > > Hi Gerd, > > > > I'm trying to use the new "road-name-config" parameter and I have a > doubt: > > > > In section 2 of the file roadNameConfig.txt there are some language > > configuration, for example "lang:FRA = fr". However, when do I tell > > mkgmap which language I'm using? In what parameter is this > > configured? Is it "country-abbr"? > > > > Thanks, > > > > Bes
Re: [mkgmap-dev] Doubt when using "road-name-config"
Thank you Carlos and Gerd by your answers. In fact, I don't use the default style, but each way is tagged with "mkgmap:country=BRA", as you can see in a partial sample extracted from a mkgmap execution with echotags: Way 6761 [addr:city=BRUMADINHO, addr:country=BRA, addr:state=MG, highway=residential, mkgmap:city=BRUMADINHO, mkgmap:country=BRA, mkgmap:label:1=RUA DAS ROSAS, mkgmap:region=MG, mkgmap:street=RUA DAS ROSAS, name=RUA DAS ROSAS] Way 13983 [addr:city=BRUMADINHO, addr:country=BRA, addr:state=MG, highway=residential, mkgmap:city=BRUMADINHO, mkgmap:country=BRA, mkgmap:label:1=RUA RUBI, mkgmap:region=MG, mkgmap:street=RUA RUBI, name=RUA RUBI] This is may roadNameConfig.txt file in this test: ## # Section 1 # prefix1: list of 1st words # prefix2: further words to combine with each prefix1 word, separated with a blank # suffix: gives list of suffix words # portugese prefix1:pt = "Rua", "Avenida", "Travessa" prefix2:pt = "da ", "do ", "de ", "das ", "dos " ## # Section 2 # Map 3 letter ISO country codes to list of used languages for road names. lang:BRA = pt lang:PRT = pt And in MapSource I'm still viewing the ways with full name prefixed bye "Rua" and "Rua das ": [image: Imagem inline 1] What can I'm doing wrong? And Gerd, in your last email you quoted the "LocatorConfig.xml" file. What file is this and where can I find it? Thanks. Alexandre 2017-06-11 12:00 GMT-03:00 Gerd Petermann : > Hi, > > Carlos is right for the default style. If you use a very different style, > make sure that mkgmap:country contains the > 3 letter iso code for the country. See also the file LocatorConfig.xml. > I'll try to make that clearer in the coments > in roadNameConfig.txt. > > https://github.com/openstreetmap/mkgmap/tree/master/resources > > Gerd > > Von: mkgmap-dev im Auftrag von > Carlos Dávila > Gesendet: Sonntag, 11. Juni 2017 15:32 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Doubt when using "road-name-config" > > El 11/06/17 a las 14:42, Alexandre Loss escribió: > > Hi Gerd, > > > > I'm trying to use the new "road-name-config" parameter and I have a > doubt: > > > > In section 2 of the file roadNameConfig.txt there are some language > > configuration, for example "lang:FRA = fr". However, when do I tell > > mkgmap which language I'm using? In what parameter is this > > configured? Is it "country-abbr"? > > > > Thanks, > > > > Best regards > > > > Alexandre Loss > > > Section 2 is used by mkgmap to know what language(s) is spoken in each > country. You don't have to tell mkgmap what language, but what country. > And it takes that info from bounds file if --bounds parameter is given. > ___ > 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Doubt when using "road-name-config"
Hi Gerd, I'm trying to use the new "road-name-config" parameter and I have a doubt: In section 2 of the file roadNameConfig.txt there are some language configuration, for example "lang:FRA = fr". However, when do I tell mkgmap which language I'm using? In what parameter is this configured? Is it "country-abbr"? Thanks, Best regards Alexandre Loss ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Please check if help is okay
0x661f. >Examples for usage: >- Assume your style adds a POI with type 0x2800 for each > addr:housenumber. >It is not useful to index those numbers, so you can use >--poi-excl-index=0x2800 >to exclude this. >- For the mentioned Oregon you may use --poi-excl-index=0x2a00-0x661f >to reduce the index size. > > > Please suggest improvements. > > ciao, > Gerd > > > Von: mkgmap-dev im Auftrag von Gerd > Petermann > Gesendet: Mittwoch, 31. Mai 2017 18:35:36 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Please check if help is okay > > Hi Alexandre, > > thanks for the hint. The options work fine together. I'll try to make that > clearer. > > Gerd > > Von: mkgmap-dev im Auftrag von > Alexandre Loss > Gesendet: Mittwoch, 31. Mai 2017 18:06:24 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Please check if help is okay > > Hi Gerd, > > it is clear your documentation for the new --road-name-config parameter. > However, what is the relation or impact using this new parameter > concomitantly with --x-split-name-index? Are they mutually exclusive? > > I suggest to clarify this in the documentation. > > Thanks. > > Regards, > > Alexandre > > 2017-05-31 4:39 GMT-03:00 Gerd Petermann > mailto:gpetermann_muenc...@hotmail.com>>: > Hi all, > > in r3963 I tried to document the new prefix / suffix stuff: > --road-name-config=file >This option handles the problem that some countries have road names > which >ofter start or end with very similar words, e.g. in France the first > word >is very often 'Rue', ofter followed by a preposition like 'de la' or > 'des'. >This leads to rather long road names like 'Rue de la Concorde' where > only >the word 'Concorde' is really interesting. In the USA, you ofter have > names >like 'West Main Street' where only the word 'Main' is important. >Garmin software has some tricks to handle this problem. It allows to > use >special characters in the road labels which mark the beginning and end > of >the important part. >There are two different visiual effects of this option: >- On the PC, when zooming out, the name 'Rue de la Concorde' is only >rendered as 'Concorde'. >- The index for road names only contains the important part of the > name. >You can search for road name Conc to find road names like 'Rue > de la Concorde'. >One problem: Search for 'Rue' will not list 'Rue de la > Concorde' >or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if that > is in the map. > >Another effect is that the index is smaller. > >The option specifies the path to a file which gives the details. See >comments in the sample roadNameConfig.txt for further details. > > Is that clear enough? Please check also the comments in the sample file. > Please suggest improvements, else I'll use the same text for the style > documentation before > merging to trunk. > > Gerd > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk<mailto: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 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] Please check if help is okay
Hi Gerd, it is clear your documentation for the new --road-name-config parameter. However, what is the relation or impact using this new parameter concomitantly with --x-split-name-index? Are they mutually exclusive? I suggest to clarify this in the documentation. Thanks. Regards, Alexandre 2017-05-31 4:39 GMT-03:00 Gerd Petermann : > Hi all, > > in r3963 I tried to document the new prefix / suffix stuff: > --road-name-config=file > This option handles the problem that some countries have road > names which > ofter start or end with very similar words, e.g. in France the > first word > is very often 'Rue', ofter followed by a preposition like 'de la' > or 'des'. > This leads to rather long road names like 'Rue de la Concorde' > where only > the word 'Concorde' is really interesting. In the USA, you ofter > have names > like 'West Main Street' where only the word 'Main' is important. > Garmin software has some tricks to handle this problem. It allows > to use > special characters in the road labels which mark the beginning and > end of > the important part. > There are two different visiual effects of this option: > - On the PC, when zooming out, the name 'Rue de la Concorde' is > only > rendered as 'Concorde'. > - The index for road names only contains the important part of the > name. > You can search for road name Conc to find road names like > 'Rue de la Concorde'. > One problem: Search for 'Rue' will not list 'Rue de la > Concorde' > or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if > that is in the map. > > Another effect is that the index is smaller. > > The option specifies the path to a file which gives the details. > See > comments in the sample roadNameConfig.txt for further details. > > Is that clear enough? Please check also the comments in the sample file. > Please suggest improvements, else I'll use the same text for the style > documentation before > merging to trunk. > > Gerd > ___ > 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] Routing problem after mkgmap r3757
Hi Gerd, Don't worry man! Every developer knows that this kind of mistake can happens when coding something. And you have credit enough in this community. The most important is that you took my report in consideration and solved the problem. By the way, sorry to include images in mail! I thought they should help. Thanks again, Alexandre Enviado do meu iPhone > Em 4 de abr de 2017, às 04:21, Gerd Petermann > escreveu: > > Hi all, > > sorry for introducing this major bug solving a minor one :-( > > The problem happened with roads that are split because of a 255 points limit > in the img format. Few OSM ways have so many points, but also sometimes the > RoadMerger > produces them by concatenating ways with similar attributes, so I think the > error is probably in all maps produced with r3757 .. r3877. > > @Alexandre: I still don't know why I forgot to react on your first mail. I > think I remember that I read it but I cannot find it anywhere in the > archives. Maybe the attached pictures > made it too big. > > Gerd > ____ > Von: mkgmap-dev im Auftrag von > Alexandre Loss > Gesendet: Dienstag, 4. April 2017 01:41:36 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Routing problem after mkgmap r3757 > > Hi Andrzej and Gerd, > > Tested with r3878 and confirmed that the problem was solved! > Thank you both very much! > > Best regards, > > Alexandre Loss > > 2017-04-03 12:11 GMT-03:00 Andrzej Popowski > mailto:po...@poczta.onet.pl>>: > Hi, > > I just have uploaded example of wrong routing in BaseCamp, only to find out, > that problem is already corrected in r3878. Thanks Gerd! > > -- > Best regards, > Andrzej > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk<mailto: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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing problem after mkgmap r3757
Hi Andrzej and Gerd, Tested with r3878 and confirmed that the problem was solved! Thank you both very much! Best regards, Alexandre Loss 2017-04-03 12:11 GMT-03:00 Andrzej Popowski : > Hi, > > I just have uploaded example of wrong routing in BaseCamp, only to find > out, that problem is already corrected in r3878. Thanks Gerd! > > -- > Best regards, > Andrzej > ___ > 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] fixme rules
In dispite we don't have this kind of problem in our Brazilian project (we don't use OSM as source for maps), I agree with you that the first option is better. Alexandre 2017-03-21 7:04 GMT-03:00 Gerd Petermann : > Hi all, > > any feedback on this? > I see several ways to improve fixme handling. > 1) add a new option --ignore-fixme-values which is used when > reading osm data and means: ignore all tags when the value matches the > fixme > pattern '(?i)fix[ _]?+me' > Disadvantage: > - Would add a regular expression check for each tag > - user has no control if he wants only certain tags to be cleaned up > - requires new option > Advantage: Removes the values before they can cause trouble in routines > which try to find a name. > (e.g. if name-list says name:de,name_loc,name) > > 2) In the style, as an include like Andrzejs patch sugested. > Disadvantages: > - Internal routines might evaluate the unwanted tags before style > processing. > - For ways the rules may be tested twice (when rules for lines and shapes > are concatenated) > (not sure if this matters) > Advantage: > - no new option needed > > I think 1) is better. > > Gerd > > > > Gerd Petermann wrote > > Hi Andrzej, > > > > yes, I agree that we have some rules which might be improved. I just try > > to make up my mind what is best. > > > > The POI for MP-relations are generated with special code which also > > searches for nodes with role=label or role=admin_centre. > > For ways not generated from MP-relations the POIGenerator checks only if > > the way is closed or not, all closed ways are treated as area. > > (all this happens before processing the rules in points, lines, or > > polygons) > > > > I've verified that the code in MultipolygonRelatiion creates multiple > > ways, all tagged with mkgmap:mp_created=true > > - One for each outer ring with tag mkgmap:stylefilter=polyline, these are > > only processed by the lines rules > > - One or more for the areas (after splitting to cut out holes) with tag > > mkgmap:stylefilter=polygon, these are only processed by the polygon rules > > > > I agree that the fixme rules should be placed in an include that is > placed > > at the beginning of points, lines and polygons, > > but what about relations? > > > > Another problem: Assume you have a way with name=XYZ and name:de=Fixme > and > > --name-tag-list=name:de,name > > I guess one would prefer to see name=XYZ instead of Fixme (or null if > > fixme rules were applied) in that case. > > > > I start to believe that the fixme handling should (again) be done in Java > > code. > > > > Gerd > > > > Von: mkgmap-dev < > > > mkgmap-dev-bounces@.org > > > > im Auftrag von Andrzej Popowski < > > > popej@.onet > > > > > > Gesendet: Donnerstag, 9. März 2017 14:44:28 > > An: > > > mkgmap-dev@.org > > > Betreff: Re: [mkgmap-dev] fixme rules > > > > Hi Gerd, > > > > I think you are considering other problem then I. I'm not talking about > > inner/outer line, but about proper recognizing if OSM object is an area. > > > > Actually a rule, which adds area=yes is already present in lines. And > > some tests for mkgmap:mp_created are present in polygons, see > > highway=pedestrian. > > > > This rule isn't useful for pois, but I wonder how mkgmap creates poi > > from areas. Does it test for multipolygon or area=yes? > > > > -- > > Best regards, > > Andrzej > > ___ > > mkgmap-dev mailing list > > > mkgmap-dev@.org > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___ > > mkgmap-dev mailing list > > > mkgmap-dev@.org > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > -- > View this message in context: http://gis.19327.n8.nabble.com/fixme-rules- > tp5892639p5893690.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > ___ > 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] Error reading license-file
Hi Patrik, Convert the license file to UTF-8 solve the problem! Thanks! Alexandre 2016-12-20 12:57 GMT-02:00 Alexandre Loss : > Hi Patrik, > > I'll try and post here the result. > > Thanks! > > Alexandre > > 2016-12-20 12:29 GMT-02:00 Patrik Brunner : > >> Alexandre, >> try to convert the license file with your editor into UTF-8 and run it >> again... >> That most problably works. >> >> Cheers >> Patrik >> >> *Gesendet:* Dienstag, 20. Dezember 2016 um 15:22 Uhr >> *Von:* "Alexandre Loss" >> *An:* "Development list for mkgmap" >> *Betreff:* [mkgmap-dev] Error reading license-file >> Hi guys, >> >> I convert a set of maps daily to my group and I've been successfully >> using mkgmap r3702. >> However, today I upgraded to r3734 and started getting the following >> error in the license file: >> >> java -Xmx14g -XX:+UseParallelGC -XX:+UseParallelOldGC >> -XX:+UseAdaptiveSizePolicy -jar ..\Ferramentas\mkgmap.jar >> --style-file=..\Ferramentas\mkgmap-style-tracksource >> --license-file="..\txt\Licenca-TS.txt" -c TS-Brasil.args >> Time started: Tue Dec 20 10:07:24 BRST 2016 >> *Error reading license file ..\txt\Licenca-TS.txt* >> *Number of ExitExceptions: 1* >> Time finished: Tue Dec 20 10:07:33 BRST 2016 >> Total time taken: 9333ms >> >> Find attached the license-file "Licenca-TS.txt". >> >> Regards, >> >> Alexandre Loss >> ___ mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailm >> an/listinfo/mkgmap-dev >> >> ___ >> 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] Error reading license-file
Hi Patrik, I'll try and post here the result. Thanks! Alexandre 2016-12-20 12:29 GMT-02:00 Patrik Brunner : > Alexandre, > try to convert the license file with your editor into UTF-8 and run it > again... > That most problably works. > > Cheers > Patrik > > *Gesendet:* Dienstag, 20. Dezember 2016 um 15:22 Uhr > *Von:* "Alexandre Loss" > *An:* "Development list for mkgmap" > *Betreff:* [mkgmap-dev] Error reading license-file > Hi guys, > > I convert a set of maps daily to my group and I've been successfully using > mkgmap r3702. > However, today I upgraded to r3734 and started getting the following error > in the license file: > > java -Xmx14g -XX:+UseParallelGC -XX:+UseParallelOldGC > -XX:+UseAdaptiveSizePolicy -jar ..\Ferramentas\mkgmap.jar > --style-file=..\Ferramentas\mkgmap-style-tracksource > --license-file="..\txt\Licenca-TS.txt" -c TS-Brasil.args > Time started: Tue Dec 20 10:07:24 BRST 2016 > *Error reading license file ..\txt\Licenca-TS.txt* > *Number of ExitExceptions: 1* > Time finished: Tue Dec 20 10:07:33 BRST 2016 > Total time taken: 9333ms > > Find attached the license-file "Licenca-TS.txt". > > Regards, > > Alexandre Loss > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Error reading license-file
Hi guys, I convert a set of maps daily to my group and I've been successfully using mkgmap r3702. However, today I upgraded to r3734 and started getting the following error in the license file: java -Xmx14g -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy -jar ..\Ferramentas\mkgmap.jar --style-file=..\Ferramentas\mkgmap-style-tracksource --license-file="..\txt\Licenca-TS.txt" -c TS-Brasil.args Time started: Tue Dec 20 10:07:24 BRST 2016 *Error reading license file ..\txt\Licenca-TS.txt* *Number of ExitExceptions: 1* Time finished: Tue Dec 20 10:07:33 BRST 2016 Total time taken: 9333ms Find attached the license-file "Licenca-TS.txt". Regards, Alexandre Loss TS BRASIL - Copyright (C) 2015 Projeto Tracksource Creative Commons 2.5 Atribuição - Uso Não-Comercial - Não a obras derivadas Você pode Copiar, Distribuir, Exibir e Executar a obra sob as seguintes condições: Atribuição: Você deve dar crédito ao autor original, da forma especificada pelo autor ou licenciante. Em caso de redistribuição em página da internet, a atribuição deve ser feita colocando-se na linha superior ou inferior daquela onde se encontra o link de download o texto: "Mapas Copyright (C) 2015 Projeto Tracksource disponíveis para download gratuito em http://www.tracksource.org.br";. Em caso de redistribuição em qualquer meio físico, deve constar na capa e/ou etiqueta o texto: "Mapas Copyright (C) 2015 Projeto Tracksource disponíveis para download gratuito em http://www.tracksource.org.br";. Uso Não-Comercial: Você não pode utilizar esta obra com finalidades comerciais. Vedada a Criação de Obras Derivadas: Você não pode alterar, transformar ou criar outra obra com base nesta. Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da licença desta obra. Qualquer uma destas condições podem ser renunciadas, desde que você obtenha permissão do autor. Nada nesta licença diminui ou restringe os direitos morais do autor. Termo de exoneração de responsabilidade disclaimer: Qualquer direito de uso legítimo (ou "fair use") concedido por lei, ou qualquer outro direito protegido pela legislação local, não são em hipótese alguma afetados pelo disposto acima. Este é um sumário para leigos da Licença Jurídica que pode ser acessada na íntegra em: http://creativecommons.org/licenses/by-nc-nd/2.5/br/legalcode Para maiores informações, contacte o Projeto Tracksource em: http://www.tracksource.org.br___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter r440 released
Hi Gerd, When I first started using Splitter, I experienced this overlapping tiles problem and can confirm that it causes routing problem at tile boundaries. I agree with this test, but I have doubt whether the best solution would be to stop Splitter or simply issue a warning message. In principle, I suggest that the test only generate a warning. Alexandre 2016-11-16 9:31 GMT-02:00 Gerd Petermann : > Hi all, > > I've fixed a major bug in splitter which results in wrong output files when > you pass a --split-file which contains > overlapping areas. See also > http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=440 > > Splitter doesn't generate such a file, but one can create such a file in an > editor (intended or accidentially) > > I am not sure what happens when you create a gmapsupp with overlapping > tiles, I'd expect problems with routing at the tile boundaries. So, I think > splitter should stop when overlaps between tiles with the same mapid prefix > are found, e.g. overlapping tiles 63240010 and 63240013 are not allowed, > while > overlapping tiles 12340001 and 43210001 would be considered okay. > I've not yet implemented this test, what do you think about it? > > Gerd > > > > -- > View this message in context: http://gis.19327.n8.nabble. > com/splitter-r440-released-tp5885986.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > ___ > 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] Commit r3702: sortAreas_v5.patch: Addoption--order-by-decreasing-area
Hi Ticker,
I think that create mkgmap:drawLevel is a great idea!
This will give developers more autonomy to decide the order of the polygons
on their maps.
Alexandre
2016-11-13 9:40 GMT-02:00 Ticker Berkin :
> I should have thought harder before replying last night. I imagine
> these river-bank polygons are a mixture of sizes, sometimes divided up
> at arbitary lines, hence they might be bigger or smaller that the
> fairway and this explains result you get.
>
> It's related to the way I handled sea where I give all sea polygons the
> same, large, areaSize, overwriting the actual size of the arbitrary
> polygons that make up the sea - this forces them to be output first and
> other features drawn on top.
>
> Keeping with the --order-by, in this case it would be better to force
> fairway to be consider small, hence overwriting the river. At the
> moment there is no way of doing this, but I was thinking about adding
> something like mkgmap:drawLevel to be used like:
>
> natural=sea
>{add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=9}
>[0x32 resolution 10]
> seamark:type=fairway
>{name 'fairway'; set mkgmap:drawLevel=0}
>[0x10307 level 2]
>
> where drawLevel takes a range of values from 0, being smaller than any
> natural area to, say, 10 which is much larger than any natural area.
> This would override the area value calculated from the polygon. Hence
> allowing control of the output ordering.
>
> In answer to some points earlier in the thread:
>
> --order-by should work correctly on large area that cover multiple sub
> -divisions and even on composite maps provided the splitter has
> preserved the full polygons in all maps that it has been split into -
> which I think it does.
>
> I did intend the areaSize to be the size of each outer-polygon, without
> subtracting the size of any inner polygons.
>
> Ticker
>
> On Sun, 2016-11-13 at 10:21 +0100, Felix Hartmann wrote:
> > I still think the best solution would be cutting out smaller polygons
> > from larger - however we would need to define two categories in the
> > polygons style-file:
> > 1. polygons that are used transparently in .typ (and will be given
> > high draworder anyhow) - these can be skipped. Also usually very
> > small polygons that you give high draworder (e.g. buildings) don't
> > need to be cut out. It's easier if they simply appear on top.
> > 2. Other polygons which usually cover large areas - here overlapping
> > smaller polygons should be cut out.
> >
> > Looking at area size of polygons of all polygons that fall under 2.
> > will be needed of course. But because of 1. we will save time as any
> > polygon that is flagged as belonging to 1. category can be skipped.
> > Main problems are anyhow forest, water, island and similar where
> > people are too lazy to use multipolygons.
> >
> > Even though wrong tagging - looking at the layer tag if present to
> > decide which polygon should be cut out should still be done.
> >
> >
> > On 13 November 2016 at 09:47, wrote:
> > > Yes, I would appreciate a draw order command for the style language
> > > very much.
> > >
> > >
> > >
> > > Von: Gerd Petermann
> > > Gesendet: Sonntag, 13. November 2016 08:22
> > > An: mkgmap-dev@lists.mkgmap.org.uk
> > > Betreff: Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch:
> > > Addoption--order-by-decreasing-area
> > >
> > > Hi,
> > >
> > > I am not sure regarding the sizes of the area. At least one of the
> > > riverbank
> > > polygons is a
> > > multipolygon with two outer rings. The size calculation treats each
> > > outer
> > > ring separately, without
> > > subtracting the area of inner rings.
> > > @Ticker: Is that intended?
> > >
> > > Besides that I think that the examples show that one needs both a
> > > draw order
> > > for types and size ordering to get reasonable results.
> > >
> > > Gerd
> > >
> > >
> > > rheinskipper1000 wrote
> > > > I eagerly awaited the order-by-decreasing-area option.
> > > >
> > > > Results are a bit different than I expected at the moment:
> > > >
> > > > My style contains:
> > > >
> > > > waterway=riverbank [0x10302 resolution 20]
> > > > seamark:type=fairway {name 'fairway'} [0x10307 level 2]
> > > >
> > > > Unfortunately the smaller (white) fairway polygons are still
> > > partly
> > > > covered by (blue) riverbank polygons:
> > > > https://mega.nz/#!NN8UWDCK!LeR_h1cJeBVDGMxFeUf48l_qARfVdKXTMzRoHj
> > > y_rEw
> > > > https://mega.nz/#!0B9AgZQJ!AZcQ9zHktIQ0D9Uq_nb_gRGG0eDGxCQaT0XuQJ
> > > aebWc
> > > >
> > > >
> > > >
> > > > Von: svn commit
> > > > Gesendet: Freitag, 11. November 2016 17:11
> > > > An:
> > >
> > > > mkgmap-svn@.org
> > >
> > > > ;
> > >
> > > > mkgmap-dev@.org
> > >
> > > > Betreff: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Add
> > > > option--order-by-decreasing-area
> > > >
> > > > Version mkgmap-r3702 was committed by gerd on Fri, 11 Nov 2016
> > > >
> > > > sortAreas_v5.patch: Add option --order-by-decreasing-area
> > > >
> > > > Patch by Ticker Berkin, slightly modifed
>
Re: [mkgmap-dev] [Patch v1] improve LinePreparer to reduce img size
Great discovery Gerd! Enviado do meu iPhone > Em 16 de jul de 2016, às 14:28, Gerd Petermann > escreveu: > > Hi all, > > > during the last days I tried to find more about the way how mkgmap stores > polygons, esp. why we have some limits. While doing that I stumbled over an > > old comment in LinePreparer.java: > > // I don't care about getting the smallest possible file size so > // err on the side of caution. > which made me curious because I do care ;-) > > > I found out that Garmin offers a "trick" in the delta encoding which allows > to reduce the needed bytes in some cases, the imgformat-1.0.pdf > > explains this in detail, search for " only the sign bit is set ". > > This "trick" helps esp. well when coastline polygons or rivers are stored. > > > I can explain this more detailed if somebody likes to know more, > > for now I'd like to hear if the trick causes any problems, I did not find any > > so far. > A binary with this and a slightly improved overview_levels_v2.patch > can be found here: > > http://files.mkgmap.org.uk/download/301/mkgmap.jar > > > Depending on the data a single tile with size ~5MB may be reduced by 50 - > 500+kB. > > Gerd > > ___ > 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] [mkgmap-svn] Commit r460: Don't try to read further NOD data when bit 0 of the flag byte is zero
Hi Gerd, What behaviors are expected in maps with this change? Thanks Alexandre Loss Enviado do meu iPhone > Em 9 de abr de 2016, às 05:42, svn commit escreveu: > > Version display-r460 was committed by gerd on Sat, 09 Apr 2016 > > Don't try to read further NOD data when bit 0 of the flag byte is zero > It seems that cGPSmapper produces files like this, probably not intended. > > Other sources like NodCheck or NodFile also should be changed, not sure yet > how. > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=display&rev=460 > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] osm combiner error
I have run with java 8 without problem until now. However, I'm running a windows 10 machine, not a mac. Alexandre 2016-03-24 5:05 GMT-03:00 Gerd Petermann : > Hi Paco, > > we compile with Java 1.7 but you can (and probably should) use the 1.8 JRE > to run it. > @Steve: Do you have an idea when we should move the build to 1.8 ? > > Gerd > > > Von: mkgmap-dev im Auftrag von > paco.ty...@free.fr > Gesendet: Donnerstag, 24. März 2016 07:55 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] osm combiner error > > Hi all, > > By the way, are splitter/mkgmap compatible with java8 now ? > > Thanks, > Paco > > - Mail original - > De: "Steve Ratcliffe" > À: "Development list for mkgmap" > Envoyé: Mardi 22 Mars 2016 17:14:45 > Objet: Re: [mkgmap-dev] osm combiner error > > > > What does Unsupported major.minor version 51.0 mean? > > This happens when you try to run with Java 6 or lower. I realise that he > says he on the latest version of Java and the previous version of osm > combiner was running OK, so there may be more to it. The last version of > mkgmap that worked with Java 6 was a long time ago. > > .. Steve > > On 22 March 2016 15:37:28 GMT+00:00, Minko wrote: > >Hi, > >On the osm forum someone reported this error with OSM combiner > >(http://www.openfietsmap.nl/news/osmcombiner) (mkgmap r.3654) > >http://forum.openstreetmap.org/viewtopic.php?id=30632 > > > >What does Unsupported major.minor version 51.0 mean? > > > >-- > > > >Unfortunately the new OSM Combiner 1.8 did not solve the problem for > >me. > >I dowloaded a fresh set of osm_generic_tiles.zip files for the > >Netherlands, Belgium and France and tried to combine them with OSM > >combiner 1.8 but consistently get an error message (see below). All > >steps up to "Start" work, the final step fails and gives the error > >message. > >I use MacOS 10.11.3 with the latest Java installed and allocated 5gb of > >memory to Java, disk space is plenty. > > > >What am I doing wrong? > > > >Thank you! > > > >--- Error message: > > > >Exception in thread "main" java.lang.UnsupportedClassVersionError: > >uk/me/parabola/mkgmap/main/Main : Unsupported major.minor version 51.0 > >at java.lang.ClassLoader.defineClass1(Native Method) > >at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) > >at java.lang.ClassLoader.defineClass(ClassLoader.java:621) > >at > >java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) > >at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) > >at java.net.URLClassLoader.access$000(URLClassLoader.java:58) > >at java.net.URLClassLoader$1.run(URLClassLoader.java:197) > >at java.security.AccessController.doPrivileged(Native Method) > >at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > >at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > >at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > >at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > >___ > >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 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch v1] change process-destination option
Hi Gerd,
Nothing regarding the limits of 10m.
I'm only saying that I keep mkgmap:exit_hint=true in my "lines" and it
continues perform as expected.
[],
Alexandre
2016-03-23 14:51 GMT-03:00 Gerd Petermann :
> Hi Alexandre,
>
>
> Thanks for testing.
>
> I see no problem with the code for process_exits, I think it only adds
>
> tags with the mkgmap prefix. Do you mean the limits regarding 10m ?
>
>
> Gerd
>
> ------
> *Von:* mkgmap-dev im Auftrag von
> Alexandre Loss
> *Gesendet:* Mittwoch, 23. März 2016 17:32
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] [Patch v1] change process-destination option
>
> Hi Gerd,
>
> After update my local mkgmap with this patch, follow my tests' results (in
> a small fictitious map):
>
> 1) Without change my proprietary style "lines" file, I get the following
> error as expected:
>
> GRAVE (StyledConverter): 03137600-lagoa_santa.osm: At least one 'lines'
> rule in the style contains the expression mkgmap:dest_hint=true, it should
> be changed to mkgmap:dest_hint=*
>
> 2) Changing mkgmap:dest_hint=true to *, as directed above, the map was
> compiled without error and the result works as expected.
>
> Therefore, I think that the patch is working like charm.
>
> I didn't change any exit_hint in lines file and the exits continue working
> as expected. Are you changing only dest_hint or are you gonna change
> dest_exit also?
>
> Regards,
>
> Alexandre
>
> 2016-03-23 6:07 GMT-03:00 Gerd Petermann
> :
>
>> Hi all,
>>
>>
>> please read carefully:
>>
>>
>> Up to now the process_destination option is a bit problematic because
>>
>> it may add the tag destination=* to an existing OSM element, and I think
>> this
>>
>> is not good, all tags added by mkgmap should have the mkgmap: prefix.
>>
>>
>> As Greg pointed out this causes problems for style authors who want to
>>
>> create special hints depending on tags like destination:street .
>>
>>
>> The attached patch changes the method like this:
>>
>> 1) the tag destination is not changed by mkgmap
>>
>> 2) Instead the special tag mkgmap:dest_hint is now set to the
>>
>> destination string that was found in one of the tags listed in this code
>> snippet:
>>
>> tags.add("destination");
>> tags.add("destination:lanes");
>> tags.add("destination:lanes:forward");
>> tags.add("destination:lanes:backward");
>> tags.add("destination:forward");
>> tags.add("destination:backward");
>> tags.add("destination:street");
>>
>>
>> (BTW: This is also the order of evaluation in mkgmap searches since
>> r3673, of cause
>>
>> forward/backward are checked depending on the direction of the way)
>>
>>
>> For style authors this means that they have to
>>
>> 1) change all rules with mkgmap:dest_hint=true to mkgmap:dest_hint=*
>>
>> 2) change the rule that produces the hint to something like this:
>> mkgmap:dest_hint=*
>> { set dest_hint = '${destination:ref|subst: =>}
>> ${mkgmap:dest_hint|subst:;=> |subst:/=> }' |
>> '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' |
>> '${mkgmap:dest_hint|subst:;=> |subst:/=> }';
>>}
>>
>> Basically all places where "destination" was used were changed to
>> mkgmap:dest_hint.
>>
>>
>> I am aware that this could cause trouble, so I've added a check that
>> complains when
>>
>> the style contains an expression mkgmap:dest_hint=true .
>>
>>
>> A binary can be found here:
>>
>> http://files.mkgmap.org.uk/download/295/mkgmap.jar
>>
>>
>> With the default style this produces the same img file as r3673.
>>
>> Please let me know if you see problems with your style.
>>
>>
>> Gerd
>>
>> ___
>> 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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch v1] change process-destination option
Hi Gerd,
After update my local mkgmap with this patch, follow my tests' results (in
a small fictitious map):
1) Without change my proprietary style "lines" file, I get the following
error as expected:
GRAVE (StyledConverter): 03137600-lagoa_santa.osm: At least one 'lines'
rule in the style contains the expression mkgmap:dest_hint=true, it should
be changed to mkgmap:dest_hint=*
2) Changing mkgmap:dest_hint=true to *, as directed above, the map was
compiled without error and the result works as expected.
Therefore, I think that the patch is working like charm.
I didn't change any exit_hint in lines file and the exits continue working
as expected. Are you changing only dest_hint or are you gonna change
dest_exit also?
Regards,
Alexandre
2016-03-23 6:07 GMT-03:00 Gerd Petermann :
> Hi all,
>
>
> please read carefully:
>
>
> Up to now the process_destination option is a bit problematic because
>
> it may add the tag destination=* to an existing OSM element, and I think
> this
>
> is not good, all tags added by mkgmap should have the mkgmap: prefix.
>
>
> As Greg pointed out this causes problems for style authors who want to
>
> create special hints depending on tags like destination:street .
>
>
> The attached patch changes the method like this:
>
> 1) the tag destination is not changed by mkgmap
>
> 2) Instead the special tag mkgmap:dest_hint is now set to the
>
> destination string that was found in one of the tags listed in this code
> snippet:
>
> tags.add("destination");
> tags.add("destination:lanes");
> tags.add("destination:lanes:forward");
> tags.add("destination:lanes:backward");
> tags.add("destination:forward");
> tags.add("destination:backward");
> tags.add("destination:street");
>
>
> (BTW: This is also the order of evaluation in mkgmap searches since r3673,
> of cause
>
> forward/backward are checked depending on the direction of the way)
>
>
> For style authors this means that they have to
>
> 1) change all rules with mkgmap:dest_hint=true to mkgmap:dest_hint=*
>
> 2) change the rule that produces the hint to something like this:
> mkgmap:dest_hint=*
> { set dest_hint = '${destination:ref|subst: =>}
> ${mkgmap:dest_hint|subst:;=> |subst:/=> }' |
> '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' |
> '${mkgmap:dest_hint|subst:;=> |subst:/=> }';
>}
>
> Basically all places where "destination" was used were changed to
> mkgmap:dest_hint.
>
>
> I am aware that this could cause trouble, so I've added a check that
> complains when
>
> the style contains an expression mkgmap:dest_hint=true .
>
>
> A binary can be found here:
>
> http://files.mkgmap.org.uk/download/295/mkgmap.jar
>
>
> With the default style this produces the same img file as r3673.
>
> Please let me know if you see problems with your style.
>
>
> Gerd
>
> ___
> 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] Minimum size for a "_link" to process "destination"
Hi Gerd, I confirmed in practical tests that dest_hint began to be generated with link of at least 10 meters. Hi Andrzej, I have many dest_hint working as a charm in links with only 2 nodes, also linking a main road to a secondary one, both two way. However, link must be oneway and at least 10m length (as discovered today). For now there is only one situation where I found that the link must be splitted. It is when the exit is over a link in "V". Let me explain better... 1. Suppose the following situation where you have a main road (red, don't care if oneway or not), a secondary road (blue) and a link (grey, oneway) with a exit/destination from main to secondary road. 2. However, the link is a way of 3 nodes, forming a "V": node 1 starting in main road; node 2 is the "V" bottom connecting the secondary road; and, node 3 is ending back in main road. [image: Imagem inline 2] Note that exit way linking main to secondary road is in fact a "leg" of the "V" with only two nodes. In this situation, the dest_hint doesn't work and I must splitte this "leg" of the link to have at least 3 nodes. Some thing like that: [image: Imagem inline 4] Splitting this way, the dest_hint works as expected. regards, Alexandre 2016-03-09 17:08 GMT-03:00 Andrzej Popowski : > Hi Gerd, > > > maybe Garmin ignores ways which are too short. > > cGPSmapper has restriction for minimum distance between routing nodes, > which is about 2.4m. Maybe there is some a reason for it? > > I guess splitting link is some kind of solution to get 2 ways and 3 nodes > for a hint, but actually it should be main road and a link as 2 ways. If > main road is oneway, then maybe you could use it instead of splitting link? > > -- > Best regards, > Andrzej > > ___ > 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] Minimum size for a "_link" to process "destination"
Yes Gerd, this probably answer the question. I'll do a practical test with
length around 10 meters and share with you know the results.
Thanks
Alexandre
Enviado do meu iPhone
> Em 9 de mar de 2016, às 15:40, Gerd Petermann
> escreveu:
>
> Hi ALexandre,
>
>
> I did not write the code but I think this snippet in LinkDestinationHook.java
> answers the question:
>
>
> if (wayLength < 10 && w.getPoints().size() < 3) {
> log.info("Way", w, "is too short (",
> wayLength," m) to cut it into several pieces. Cannot place exit hint.");
> continue;
> }
>
> I must confess that I don't understand this limit, maybe it was introduced to
> avoid zig-zagging lines, maybe Garmin ignores
>
> ways which are too short.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag von
> Alexandre Loss
> Gesendet: Mittwoch, 9. März 2016 17:55
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Minimum size for a "_link" to process "destination"
>
> Hi mkgmap developers,
>
> I noticed that when a "_link" containing the tag "destination" (trunk_link,
> for example) is too small, mkgmap doesn't preprocesse the exit (set
> dest_hint). For example, if this "_link" has only 8 meters size, no
> destination nor exit hint is generated by mkgmap for this specific "_link".
>
> Could you tell me the "_exit" minimum lenght considered by mkgmap to process
> destination hint?
>
> Thanks.
>
> Best regards,
>
> Alexandre Loss
> ___
> 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] Minimum size for a "_link" to process "destination"
Hi mkgmap developers, I noticed that when a "_link" containing the tag "destination" (trunk_link, for example) is too small, mkgmap doesn't preprocesse the exit (set dest_hint). For example, if this "_link" has only 8 meters size, no destination nor exit hint is generated by mkgmap for this specific "_link". Could you tell me the "_exit" minimum lenght considered by mkgmap to process destination hint? Thanks. Best regards, Alexandre Loss ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Should we have a ADVANCED_DEFAULT Style?
I agree with Dave. I think that not all customizations are interesting for everybody. However, should be a good idea keep advanced implementations and examples in a Wikipedia topic, for example. So, anyone can contribute with great ideas and share with the community. Regards, Alexandre Loss Enviado do meu iPhone > Em 8 de mar de 2016, às 01:46, Dave Swarthout > escreveu: > > I doubt people want to keep their styles secret but I could be mistaken. It > is more likely that my styles and POI icons, or someone elses, are not ones > you would particularly care about. For example, I have special POIs for > milestones (common in Thailand), and assorted trees (trees common in > Thailand) and style rules that test for them and place them on my maps. In > addition, everything I'm developing is in a continual state of flux — I'm > changing rules and icons all the time as my ideas about what's important (or > fun) to map change. > > Would my styles and TYP file be of any interest to you? > > If so, merely say the word and I'll post them in my Dropbox and send you the > links. > > Best > Dave > >> On Tue, Mar 8, 2016 at 9:13 AM, greg crago wrote: >> I see many good questions about advanced mapping techniques and I am trying >> to incorporate these ideas into my maps. >> >> I was wondering if we could combine these ideas into a ADVANCED_DEFAULT >> style? >> >> I do not know if everyone wants to keep their own mapping styles secret, but >> I have added to the default_style and do not mind sharing my own additions. >> >> That way new mappers can analyze this code and get up to speed faster and >> maybe be able to add more ideas to the community. >> >> If you do not like a feature, you can always remove that piece of code. >> >> My goal is to try to use mkgmap to map maps that look like Garmin City >> Navigator. >> >> So far I have added custom POI symbols for brand specific businesses (fuel, >> fast food, resturants) >> >> Added 1 way arrows >> Added Bridges over ways >> Added Bicycle lanes. >> >> Greg >> >> ___ >> mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > ___ > 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] POI (point) resolution problem
Hi Gerd, I'm slow to answer you because I'm unable to reproduce the problem with the cGPSmapper. I mean that I'm getting the same behavior (problem) in resolution of Hospitals and Police in maps compiled with mkgmap e cgpsmapper. Which leads me to believe that Thorsten was right in saying that this behavior was normal. Perhaps it is I who hadn't seen that cGPSmapper behaved this way before. So I thank you and Thorsten for your attention and if someday I can replicate the problem I return it. Regards, Alexandre 2016-02-15 4:15 GMT-02:00 Gerd Petermann : > Hi Alexandre, > > > okay, I was able to reproduce the problem, but I think that mkgmap writes > correct data, > > GPSMapEdit seems to confirm this. Please post a link to the files produced > with cGPSmapper > > and the sources for it. Maybe there is a bit flag that controls this > behaviour. > > > Gerd > > > > > -- > *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < > mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss < > alexandre.l...@gmail.com> > *Gesendet:* Sonntag, 14. Februar 2016 23:09 > *An:* Development list for mkgmap > *Betreff:* Re: [mkgmap-dev] POI (point) resolution problem > > Hi Gerd, > > I done the 2xCtrl-G and the problem persist. > > Recapping, I tested with default style to make sure to use the standard. > If you need examples, you can test with aeroway=airport (0x2f04) that is > one type of POI that works as expected (resolution is reflected in the > img); and amenity=police (0x3001) which is one where change resolution in > points file doesn't have any effect. > > Alexandre > > 2016-02-14 19:06 GMT-02:00 Gerd Petermann >: > >> Hi ALexandre, >> >> >> okay, I'll try to reproduce the problem with the default style. >> >> Did you make sure that you press 2xCtrl+G to flush the cache >> >> in Mapsource after changing the map ? >> >> >> Gerd >> >> >> -- >> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < >> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss < >> alexandre.l...@gmail.com> >> *Gesendet:* Sonntag, 14. Februar 2016 22:00 >> >> *An:* Development list for mkgmap >> *Cc:* Tracksource Adm Tec >> *Betreff:* Re: [mkgmap-dev] POI (point) resolution problem >> >> Hi Gerd, >> >> I reported a problem where I was changing the resolution of a POI of type >> amenity:police in the style file point, and this change wasn't been >> reflected in the img file produced by mkgmap (it wasn't being shown in the >> expected zoom level). >> >> Then Thorsten answered me that this is the normal behavior because some >> kind of Garmin code for POI are shown in fixed resolution or following >> specific rules depending of the device or software where the img map is >> installed. So, this means that don't care what resolution I configure in >> point, it will be ignored. >> >> So, in my last mail I was saying that I disagree with Thorsten position, >> because when I was using cgpsmapper, I was able to change the resolution of >> these POI and they were correctly shown in Mapsource and many devices. I >> mean, if cgpsmapper was able the generate img files respecting the >> configured resolution, then probably, the fact of points configuration be >> ignored should be a mkgmap fault instead of a hardware/software environment >> rule. >> >> Thanks, >> >> Alexandre >> >> >> 2016-02-14 16:03 GMT-02:00 Gerd Petermann < >> gpetermann_muenc...@hotmail.com>: >> >>> Hi Alexandre, >>> >>> >>> not sure what you mean here. Do you say that mkgmap produces wrong >>> output >>> >>> or do you miss an option that cGPSmapper provides? >>> >>> >>> Gerd >>> >>> >>> -- >>> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < >>> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss < >>> alexandre.l...@gmail.com> >>> *Gesendet:* Sonntag, 14. Februar 2016 13:39 >>> *An:* Development list for mkgmap >>> *Cc:* Tracksource Adm Tec >>> *Betreff:* Re: [mkgmap-dev] POI (point) resolution problem >>> >>> Hi Thorsten, >>> >>> I beg to differ, but I still think this resolution problem is a >>> deficiency in mkgmap because in cGPSmapper we got more control and freedom >>> in the resolution setting of POIs, reg
Re: [mkgmap-dev] POI (point) resolution problem
Hi Gerd, I done the 2xCtrl-G and the problem persist. Recapping, I tested with default style to make sure to use the standard. If you need examples, you can test with aeroway=airport (0x2f04) that is one type of POI that works as expected (resolution is reflected in the img); and amenity=police (0x3001) which is one where change resolution in points file doesn't have any effect. Alexandre 2016-02-14 19:06 GMT-02:00 Gerd Petermann : > Hi ALexandre, > > > okay, I'll try to reproduce the problem with the default style. > > Did you make sure that you press 2xCtrl+G to flush the cache > > in Mapsource after changing the map ? > > > Gerd > > > -- > *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < > mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss < > alexandre.l...@gmail.com> > *Gesendet:* Sonntag, 14. Februar 2016 22:00 > > *An:* Development list for mkgmap > *Cc:* Tracksource Adm Tec > *Betreff:* Re: [mkgmap-dev] POI (point) resolution problem > > Hi Gerd, > > I reported a problem where I was changing the resolution of a POI of type > amenity:police in the style file point, and this change wasn't been > reflected in the img file produced by mkgmap (it wasn't being shown in the > expected zoom level). > > Then Thorsten answered me that this is the normal behavior because some > kind of Garmin code for POI are shown in fixed resolution or following > specific rules depending of the device or software where the img map is > installed. So, this means that don't care what resolution I configure in > point, it will be ignored. > > So, in my last mail I was saying that I disagree with Thorsten position, > because when I was using cgpsmapper, I was able to change the resolution of > these POI and they were correctly shown in Mapsource and many devices. I > mean, if cgpsmapper was able the generate img files respecting the > configured resolution, then probably, the fact of points configuration be > ignored should be a mkgmap fault instead of a hardware/software environment > rule. > > Thanks, > > Alexandre > > > 2016-02-14 16:03 GMT-02:00 Gerd Petermann >: > >> Hi Alexandre, >> >> >> not sure what you mean here. Do you say that mkgmap produces wrong output >> >> or do you miss an option that cGPSmapper provides? >> >> >> Gerd >> >> >> -- >> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < >> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss < >> alexandre.l...@gmail.com> >> *Gesendet:* Sonntag, 14. Februar 2016 13:39 >> *An:* Development list for mkgmap >> *Cc:* Tracksource Adm Tec >> *Betreff:* Re: [mkgmap-dev] POI (point) resolution problem >> >> Hi Thorsten, >> >> I beg to differ, but I still think this resolution problem is a >> deficiency in mkgmap because in cGPSmapper we got more control and freedom >> in the resolution setting of POIs, regardless of device or software. >> >> Thanks. >> >> Alexandre >> >> >>> >>>> -- Forwarded message -- >>>> From: Thorsten Kukuk >>>> Date: 2016-02-12 10:02 GMT-02:00 >>>> Subject: Re: [mkgmap-dev] POI (point) resolution problem >>>> To: mkgmap-dev@lists.mkgmap.org.uk >>>> >>>> >>>> >>>> Hi, >>>> >>>> On Fri, Feb 12, Alexandre Loss wrote: >>>> >>>> > Hi guys, >>>> > >>>> > I have noticed that the resolution set in the styles' point file is >>>> not >>>> > considered for some types of POI. >>>> > I'm not sure if this behavior is my fault or a mkgmap bug and >>>> therefore I >>>> > ask your help. >>>> >>>> The resolution of POIs depend on the device/software you use to display >>>> the map, not on the map itself. It's hardcoded in the devices and >>>> software. >>>> You could only try to use another POI number. >>>> >>>> Thorsten >>>> >>>> -- >>>> Thorsten Kukuk, Senior Architect SLES & Common Code Base >>>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany >>>> GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG >>>> Nürnberg) >>>> ___ >>>> 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 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] POI (point) resolution problem
Hi Gerd, I didn't do that flush, but I'll do right now and let you know the result. Thanks, Alexandre 2016-02-14 19:06 GMT-02:00 Gerd Petermann : > Hi ALexandre, > > > okay, I'll try to reproduce the problem with the default style. > > Did you make sure that you press 2xCtrl+G to flush the cache > > in Mapsource after changing the map ? > > > Gerd > > > -- > *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < > mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss < > alexandre.l...@gmail.com> > *Gesendet:* Sonntag, 14. Februar 2016 22:00 > > *An:* Development list for mkgmap > *Cc:* Tracksource Adm Tec > *Betreff:* Re: [mkgmap-dev] POI (point) resolution problem > > Hi Gerd, > > I reported a problem where I was changing the resolution of a POI of type > amenity:police in the style file point, and this change wasn't been > reflected in the img file produced by mkgmap (it wasn't being shown in the > expected zoom level). > > Then Thorsten answered me that this is the normal behavior because some > kind of Garmin code for POI are shown in fixed resolution or following > specific rules depending of the device or software where the img map is > installed. So, this means that don't care what resolution I configure in > point, it will be ignored. > > So, in my last mail I was saying that I disagree with Thorsten position, > because when I was using cgpsmapper, I was able to change the resolution of > these POI and they were correctly shown in Mapsource and many devices. I > mean, if cgpsmapper was able the generate img files respecting the > configured resolution, then probably, the fact of points configuration be > ignored should be a mkgmap fault instead of a hardware/software environment > rule. > > Thanks, > > Alexandre > > > 2016-02-14 16:03 GMT-02:00 Gerd Petermann >: > >> Hi Alexandre, >> >> >> not sure what you mean here. Do you say that mkgmap produces wrong output >> >> or do you miss an option that cGPSmapper provides? >> >> >> Gerd >> >> >> -- >> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < >> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss < >> alexandre.l...@gmail.com> >> *Gesendet:* Sonntag, 14. Februar 2016 13:39 >> *An:* Development list for mkgmap >> *Cc:* Tracksource Adm Tec >> *Betreff:* Re: [mkgmap-dev] POI (point) resolution problem >> >> Hi Thorsten, >> >> I beg to differ, but I still think this resolution problem is a >> deficiency in mkgmap because in cGPSmapper we got more control and freedom >> in the resolution setting of POIs, regardless of device or software. >> >> Thanks. >> >> Alexandre >> >> >>> >>>> -- Forwarded message -- >>>> From: Thorsten Kukuk >>>> Date: 2016-02-12 10:02 GMT-02:00 >>>> Subject: Re: [mkgmap-dev] POI (point) resolution problem >>>> To: mkgmap-dev@lists.mkgmap.org.uk >>>> >>>> >>>> >>>> Hi, >>>> >>>> On Fri, Feb 12, Alexandre Loss wrote: >>>> >>>> > Hi guys, >>>> > >>>> > I have noticed that the resolution set in the styles' point file is >>>> not >>>> > considered for some types of POI. >>>> > I'm not sure if this behavior is my fault or a mkgmap bug and >>>> therefore I >>>> > ask your help. >>>> >>>> The resolution of POIs depend on the device/software you use to display >>>> the map, not on the map itself. It's hardcoded in the devices and >>>> software. >>>> You could only try to use another POI number. >>>> >>>> Thorsten >>>> >>>> -- >>>> Thorsten Kukuk, Senior Architect SLES & Common Code Base >>>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany >>>> GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG >>>> Nürnberg) >>>> ___ >>>> 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 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] POI (point) resolution problem
Hi Gerd, I reported a problem where I was changing the resolution of a POI of type amenity:police in the style file point, and this change wasn't been reflected in the img file produced by mkgmap (it wasn't being shown in the expected zoom level). Then Thorsten answered me that this is the normal behavior because some kind of Garmin code for POI are shown in fixed resolution or following specific rules depending of the device or software where the img map is installed. So, this means that don't care what resolution I configure in point, it will be ignored. So, in my last mail I was saying that I disagree with Thorsten position, because when I was using cgpsmapper, I was able to change the resolution of these POI and they were correctly shown in Mapsource and many devices. I mean, if cgpsmapper was able the generate img files respecting the configured resolution, then probably, the fact of points configuration be ignored should be a mkgmap fault instead of a hardware/software environment rule. Thanks, Alexandre 2016-02-14 16:03 GMT-02:00 Gerd Petermann : > Hi Alexandre, > > > not sure what you mean here. Do you say that mkgmap produces wrong output > > or do you miss an option that cGPSmapper provides? > > > Gerd > > > -- > *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < > mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss < > alexandre.l...@gmail.com> > *Gesendet:* Sonntag, 14. Februar 2016 13:39 > *An:* Development list for mkgmap > *Cc:* Tracksource Adm Tec > *Betreff:* Re: [mkgmap-dev] POI (point) resolution problem > > Hi Thorsten, > > I beg to differ, but I still think this resolution problem is a deficiency > in mkgmap because in cGPSmapper we got more control and freedom in the > resolution setting of POIs, regardless of device or software. > > Thanks. > > Alexandre > > >> >>> -- Forwarded message -- >>> From: Thorsten Kukuk >>> Date: 2016-02-12 10:02 GMT-02:00 >>> Subject: Re: [mkgmap-dev] POI (point) resolution problem >>> To: mkgmap-dev@lists.mkgmap.org.uk >>> >>> >>> >>> Hi, >>> >>> On Fri, Feb 12, Alexandre Loss wrote: >>> >>> > Hi guys, >>> > >>> > I have noticed that the resolution set in the styles' point file is not >>> > considered for some types of POI. >>> > I'm not sure if this behavior is my fault or a mkgmap bug and >>> therefore I >>> > ask your help. >>> >>> The resolution of POIs depend on the device/software you use to display >>> the map, not on the map itself. It's hardcoded in the devices and >>> software. >>> You could only try to use another POI number. >>> >>> Thorsten >>> >>> -- >>> Thorsten Kukuk, Senior Architect SLES & Common Code Base >>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany >>> GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG >>> Nürnberg) >>> ___ >>> 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POI (point) resolution problem
Hi Thorsten, I beg to differ, but I still think this resolution problem is a deficiency in mkgmap because in cGPSmapper we got more control and freedom in the resolution setting of POIs, regardless of device or software. Thanks. Alexandre > >> -- Forwarded message -- >> From: Thorsten Kukuk >> Date: 2016-02-12 10:02 GMT-02:00 >> Subject: Re: [mkgmap-dev] POI (point) resolution problem >> To: mkgmap-dev@lists.mkgmap.org.uk >> >> >> >> Hi, >> >> On Fri, Feb 12, Alexandre Loss wrote: >> >> > Hi guys, >> > >> > I have noticed that the resolution set in the styles' point file is not >> > considered for some types of POI. >> > I'm not sure if this behavior is my fault or a mkgmap bug and therefore >> I >> > ask your help. >> >> The resolution of POIs depend on the device/software you use to display >> the map, not on the map itself. It's hardcoded in the devices and >> software. >> You could only try to use another POI number. >> >> Thorsten >> >> -- >> Thorsten Kukuk, Senior Architect SLES & Common Code Base >> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany >> GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG >> Nürnberg) >> ___ >> 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] POI (point) resolution problem
Thanks Kukuk by your answer! Regards, Alexandre 2016-02-12 10:02 GMT-02:00 Thorsten Kukuk : > > Hi, > > On Fri, Feb 12, Alexandre Loss wrote: > > > Hi guys, > > > > I have noticed that the resolution set in the styles' point file is not > > considered for some types of POI. > > I'm not sure if this behavior is my fault or a mkgmap bug and therefore I > > ask your help. > > The resolution of POIs depend on the device/software you use to display > the map, not on the map itself. It's hardcoded in the devices and software. > You could only try to use another POI number. > > Thorsten > > -- > Thorsten Kukuk, Senior Architect SLES & Common Code Base > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG > Nürnberg) > ___ > 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] POI (point) resolution problem
Hi guys, I have noticed that the resolution set in the styles' point file is not considered for some types of POI. I'm not sure if this behavior is my fault or a mkgmap bug and therefore I ask your help. To report the problem I have prepared a small fictitious map containing only two streets, a city point, a airport point and a police station point (the attachment 03137600-lagoa_santa.osm). I'm using the latest version of mkgmap (3666) and the original default styles as-is. Attached also the arguments file used: TRU-Teste.args And I'm running mkgmap whit the following command: java -jar mkgmap.jar --style-file=default -c TRU-Teste.args *The first test* In the first test I set/left the resolution as follow: aeroway=airport [0x2f04 resolution 22] amenity=police [0x3001 resolution *24*] And the following images are the results zooming in Mapsource. As expected, the police point starts to be visible in a zoom of 200m: [image: Imagem inline 1] [image: Imagem inline 2] [image: Imagem inline 3] *The second test* In the second test, I changed the police resolution to 20, expecting that Police begins to be visible before than airport. aeroway=airport [0x2f04 resolution 22] amenity=police [0x3001 resolution *20*] However, as you can see in the below images extracted from Mapsource, police point continues to be visible only from a zoom of 200m. [image: Imagem inline 5] [image: Imagem inline 4] So, that's it! Do you have any idea of whats wrong? Thanks, Alexandre Loss 03137600-lagoa_santa.osm Description: Binary data TRU-Teste.args Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Create different Maps with working routing between them - is it possible?
Hi Enrico, After join them with osmosis, you can try to split the huge resultant map with Splitter tool. It will produce some smaller rectangular maps routable among them. Regards, Alexandre Loss Enviado do meu iPhone > Em 21 de jan de 2016, às 13:08, Enrico Liboni escreveu: > > Folks, if I download two countries pbf from geofabrik, merge them via osmosis > and then build a single img map routing works fine across the countries. > > If I create two img files, one per country and put it on my garmin device, > enable both maps, I can see all the ways seems correctly linked but routing > across the two countries (maps) fails. > > Is that the expected behavior or am I doing somehting wrong? > > Thanks, > Enrico > ___ > 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] [patch v1] don't route the highway=construction ways
I agree also that "mkgmap:ignore-for-routing=yes" is more clear. 2015-10-16 15:05 GMT-03:00 Gerd Petermann : > Hi Ben, > > > thanks for the feedback. I also think that mkgmap:ignore-for-routing=yes > is better. > > > Gerd > > > -- > *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < > mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ben Konrath < > b...@bagu.org> > *Gesendet:* Freitag, 16. Oktober 2015 19:52 > *An:* Development list for mkgmap > *Betreff:* Re: [mkgmap-dev] [patch v1] don't route the > highway=construction ways > > Hi Gerd, > > Thanks for creating this patch. I ran a build with the patch and > everything seemed work fine. I installed the map into BaseCamp without > problems. I didn't specifically test a highway=construction way though. > > As for the option name, using something like > 'mkgmap:ignore-for-routing=yes' would be better because it makes the option > easier to understand at a glance for people, such as myself, who don't know > the nomenclature of the Garmin map format. > > Thanks, Ben > > On Wed, Oct 14, 2015 at 12:04 PM, Gerd Petermann < > gpetermann_muenc...@hotmail.com> wrote: > >> sorry, forgot to mention that GPSMapEdit seems to have a problem with >> these roads. It shows the road as routable with more or less unpredictable >> attributes. But Garmin software seems to work fine. >> >> Gerd >> >> -- >> From: gpetermann_muenc...@hotmail.com >> To: mkgmap-dev@lists.mkgmap.org.uk >> Date: Wed, 14 Oct 2015 12:02:23 +0200 >> Subject: [mkgmap-dev] [patch v1] don't route the highway=construction >> ways >> >> >> Hi all, >> >> attached patch implements the new internal tag >> mkgmap:add-to-NOD=false >> to handle the issue discussed here: >> >> http://gis.19327.n5.nabble.com/don-t-route-through-highway-construction-tt5856734.html >> >> It shows how to use it in the default style. >> I've also added a rule to ignore highway=planned like highway=proposed >> >> If you don't like the rather technical name mkgmap:add-to-NOD, please let >> me know it, >> here are my ideas for alternatives: >> mkgmap:ignore-for-routing=yes >> mkgmap:routable=no >> mkgmap:address-search-only=yes >> >> Gerd >> >> ___ 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 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] Change Brazil to Brasil...
Hi Gerd, It works like a charm! Thanks! Regards, Alexandre 2015-10-15 10:15 GMT-03:00 Alexandre Loss : > Thanks Gerd! > > I saw you committed v3644 with this patch. I will test later and give you > a feedback. > > Regards, > > Alexandre > > (Enviado via iPad) > > Em 15 de out de 2015, às 04:04, Gerd Petermann < > gpetermann_muenc...@hotmail.com> escreveu: > > Hi Alexandre, > > it seems Brazil and Brasil are both often used, > so what about this: > > BR > BRA > Brazil > > > Gerd > > -- > Date: Wed, 14 Oct 2015 22:37:02 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] Change Brazil to Brasil... > > Dear mkgmap developers, > > Is it possible to alter the LocatorConfig.xml, changing the spelling of > Brazil to Portuguese? > Brasil with "s" instead of "z". I.e.: > > > > BR > BRA > > > I'm doing the change manually ever new version, but if you can change in > the source it will better for sure. > > Thanks. > > Alexandre Loss > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Change Brazil to Brasil...
Thanks Gerd! I saw you committed v3644 with this patch. I will test later and give you a feedback. Regards, Alexandre (Enviado via iPad) > Em 15 de out de 2015, às 04:04, Gerd Petermann > escreveu: > > Hi Alexandre, > > it seems Brazil and Brasil are both often used, > so what about this: > > BR > BRA > Brazil > > > Gerd > > Date: Wed, 14 Oct 2015 22:37:02 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] Change Brazil to Brasil... > > Dear mkgmap developers, > > Is it possible to alter the LocatorConfig.xml, changing the spelling of > Brazil to Portuguese? > Brasil with "s" instead of "z". I.e.: > > > > BR > BRA > > > I'm doing the change manually ever new version, but if you can change in the > source it will better for sure. > > Thanks. > > Alexandre Loss > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Change Brazil to Brasil...
Hi Gerd! I believe that doing this way will work fine. Thanks. Regards, Alexandre 2015-10-15 4:04 GMT-03:00 Gerd Petermann : > Hi Alexandre, > > it seems Brazil and Brasil are both often used, > so what about this: > > BR > BRA > Brazil > > > Gerd > > -- > Date: Wed, 14 Oct 2015 22:37:02 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] Change Brazil to Brasil... > > > Dear mkgmap developers, > > Is it possible to alter the LocatorConfig.xml, changing the spelling of > Brazil to Portuguese? > Brasil with "s" instead of "z". I.e.: > > > > BR > BRA > > > I'm doing the change manually ever new version, but if you can change in > the source it will better for sure. > > Thanks. > > Alexandre Loss > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Change Brazil to Brasil...
Dear mkgmap developers, Is it possible to alter the LocatorConfig.xml, changing the spelling of Brazil to Portuguese? Brasil with "s" instead of "z". I.e.: BR BRA I'm doing the change manually ever new version, but if you can change in the source it will better for sure. Thanks. Alexandre Loss ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Numbering loss in the version which came after the r3602
So... Does this means that you fix it? It's good to hear this, because in that example I sent, in fact there was an error in data. But as soon I share this in my group, I receive a storm of examples were the data are similar that, but aren't problem in data. Alexandre (Enviado via iPad) > Em 19/08/2015, às 02:49, Gerd Petermann > escreveu: > > Hi Alexandre, > > okay, good to hear that. I decided to make mkgmap tests regarding > addr:interpolation ways rather strict > because in some areas (mostly Canada) these errors appear extremely often, > caused by bad imports. > Seems to be a generel problem of OSM generators ;-) > > Gerd > Date: Tue, 18 Aug 2015 15:40:40 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > CC: adm_tec_tracksou...@googlegroups.com > Subject: Re: [mkgmap-dev] Numbering loss in the version which came after the > r3602 > > Hi Gerd, > > I'm sorry the delay to answer, but I came on vacation and had many pending > issues waiting for me. > Regard this specific issue, your interpretation of the problem of > duplication/overlap in the numbering interpolation is correct. In fact the > data doesn't make sense and I agree with you that this case is an error in > the data. > > To prove this, I got the short example sent before and correctly input the > numbers eliminating the overlapping as shown below: > > > > > > And then I compiled the map with mkgmap versions 3612 and 3629 (the last one > I found) and the numbers were not "missed" this time, proving you theory. > > Snapshot taken form MapSource of a map compiled wiht mkgmap r3612 > > > Snapshot taken form MapSource of a map compiled wiht mkgmap r3629 > > > So I think we can close the case and I have some work do clean the maps of my > group. > > Thanks again for your attention and analysis. > > Best regards, > > Alexandre Loss > > 2015-07-21 9:06 GMT-03:00 Alexandre Loss : > Hi Gerd and Steve, > > Thanks by your attention. > I'm in vocation now and without access to my computer, so I can't provide > more information if you need till my return in beginning of August. > But I think that the data is correct because in despite the streets have the > same name, they are different road since they aren't connect (there is a gap > / a block between them). > So I believe that the algo couldn't consider the name of street. > But I understand your point of view, since it looks that can have a number > overlapping/shadow of both streets, what would be a logical error. > > Unfortunately, I can make more test these days but as soon I come back I > will. > > Thanks, > > Alexandre > > (Enviado via iPad) > > Em 21/07/2015, às 06:21, Gerd Petermann > escreveu: > > Hi Alexandre, > > I think the problem here is that you have two ways named "RUA PORTO ALEGRE", > one with id 2, the other with id 46, and both are in the same city. > So far no problem, but the addr:interpolation ways on those two roads > also produce a bunch of duplicate numbers. > As a result, the new algo decides to ignore them. > Unfortunately, the log > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator > e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to > different roads in cluster RUA PORTO ALEGRE 2(0) 2(1) > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator > e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to > different roads in cluster RUA PORTO ALEGRE 3(0) 3(1) > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/13 > 800..2, step=2 generated even interpolated number(s) for id=2, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/14 > 801..3, step=2 generated odd interpolated number(s) for id=2, RUA PORTO ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 > 419..205, step=2 generated odd interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 > 203..3, step=2 generated odd interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 > 418..204, step=2 gener
Re: [mkgmap-dev] Numbering loss in the version which came after the r3602
Hi Gerd, I'm sorry the delay to answer, but I came on vacation and had many pending issues waiting for me. Regard this specific issue, your interpretation of the problem of duplication/overlap in the numbering interpolation is correct. In fact the data doesn't make sense and I agree with you that this case is an error in the data. To prove this, I got the short example sent before and correctly input the numbers eliminating the overlapping as shown below: [image: Imagem inline 3] And then I compiled the map with mkgmap versions 3612 and 3629 (the last one I found) and the numbers were not "missed" this time, proving you theory. *Snapshot taken form MapSource of a map compiled wiht mkgmap r3612* [image: Imagem inline 1] *Snapshot taken form MapSource of a map compiled wiht mkgmap r3629* [image: Imagem inline 2] So I think we can close the case and I have some work do clean the maps of my group. Thanks again for your attention and analysis. Best regards, Alexandre Loss 2015-07-21 9:06 GMT-03:00 Alexandre Loss : > Hi Gerd and Steve, > > Thanks by your attention. > I'm in vocation now and without access to my computer, so I can't provide > more information if you need till my return in beginning of August. > But I think that the data is correct because in despite the streets have > the same name, they are different road since they aren't connect (there is > a gap / a block between them). > So I believe that the algo couldn't consider the name of street. > But I understand your point of view, since it looks that can have a number > overlapping/shadow of both streets, what would be a logical error. > > Unfortunately, I can make more test these days but as soon I come back I > will. > > Thanks, > > Alexandre > > (Enviado via iPad) > > Em 21/07/2015, às 06:21, Gerd Petermann > escreveu: > > Hi Alexandre, > > I think the problem here is that you have two ways named "RUA PORTO > ALEGRE", > one with id 2, the other with id 46, and both are in the same city. > So far no problem, but the addr:interpolation ways on those two roads > also produce a bunch of duplicate numbers. > As a result, the new algo decides to ignore them. > Unfortunately, the log > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator > e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to > different roads in cluster RUA PORTO ALEGRE 2(0) 2(1) > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator > e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to > different roads in cluster RUA PORTO ALEGRE 3(0) 3(1) > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/13 > 800..2, step=2 generated even interpolated number(s) for id=2, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/14 > 801..3, step=2 generated odd interpolated number(s) for id=2, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 > 419..205, step=2 generated odd interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 > 203..3, step=2 generated odd interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 > 418..204, step=2 generated even interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 > 202..2, step=2 generated even interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator > e:\testdata\03205200-vila_velha.osm: found problems with interpolated > numbers from addr:interpolations ways for roads with name RUA PORTO ALEGRE > > > is not very clear about the reason and the final action, but I think the > data is not okay and the algo is correct > to ignore it. > > What do you think? > Gerd > > -- > Date: Wed, 17 Jun 2015 15:28:04 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > CC: adm_tec_tracksou...@googlegroups.com > Subject: Re: [mkgmap-dev] Numbering loss in the version which came after > the r3602 > > Hi Andrzej, > > Ok, thank yo
Re: [mkgmap-dev] Numbering loss in the version which came after the r3602
Hi Gerd and Steve, Thanks by your attention. I'm in vocation now and without access to my computer, so I can't provide more information if you need till my return in beginning of August. But I think that the data is correct because in despite the streets have the same name, they are different road since they aren't connect (there is a gap / a block between them). So I believe that the algo couldn't consider the name of street. But I understand your point of view, since it looks that can have a number overlapping/shadow of both streets, what would be a logical error. Unfortunately, I can make more test these days but as soon I come back I will. Thanks, Alexandre (Enviado via iPad) > Em 21/07/2015, às 06:21, Gerd Petermann > escreveu: > > Hi Alexandre, > > I think the problem here is that you have two ways named "RUA PORTO ALEGRE", > one with id 2, the other with id 46, and both are in the same city. > So far no problem, but the addr:interpolation ways on those two roads > also produce a bunch of duplicate numbers. > As a result, the new algo decides to ignore them. > Unfortunately, the log > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator > e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to > different roads in cluster RUA PORTO ALEGRE 2(0) 2(1) > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator > e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to > different roads in cluster RUA PORTO ALEGRE 3(0) 3(1) > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/13 > 800..2, step=2 generated even interpolated number(s) for id=2, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/14 > 801..3, step=2 generated odd interpolated number(s) for id=2, RUA PORTO ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 > 419..205, step=2 generated odd interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 > 203..3, step=2 generated odd interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 > 418..204, step=2 generated even interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl > e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 > 202..2, step=2 generated even interpolated number(s) for id=46, RUA PORTO > ALEGRE > FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator > e:\testdata\03205200-vila_velha.osm: found problems with interpolated numbers > from addr:interpolations ways for roads with name RUA PORTO ALEGRE > > > is not very clear about the reason and the final action, but I think the data > is not okay and the algo is correct > to ignore it. > > What do you think? > Gerd > > Date: Wed, 17 Jun 2015 15:28:04 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > CC: adm_tec_tracksou...@googlegroups.com > Subject: Re: [mkgmap-dev] Numbering loss in the version which came after the > r3602 > > Hi Andrzej, > > Ok, thank you for your time and analyses. > Lets wait for Gerd. > > regards, > Alexandre > > > 2015-06-17 13:13 GMT-03:00 Andrzej Popowski : > Hi Alexandre, > > I confirm, that there is no address on your map with current mkgmap. Data > seems to be OK, so lets wait for Gerd opinion. > > > -- > Best regards, > Andrzej > ___ > 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 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] "too many restrictions" mkgmap message
Hi Steve, You gave me a good tip to check my style. Yea! In fact I might have some extra and unnecessary restrictions being generated in the style. I need to review this, because I made this style sometime ago and never revisited it for a review. So this will be my first approach. Thanks. Regards, Alexandre 2015-07-02 17:47 GMT-03:00 Steve Ratcliffe : > Hi Alexandre > > I'm getting the error "too many restrictions" when compiling one of my >> maps with the as you can see in the out put bellow: >> > > It means that there are more than 32767 restrictions for a group of > roads. A group of roads is usually around 100 or 200 or so. > > It seems unlikely that there would be genuinely that many restrictions, > but if there is then it is possible that the format supports it and I could > try to modify the code to accept it. > > More likely it seems to me that a bug in the code results in it thinking > that there are lots more than there realy are under some condition, or > perhaps your style creates multiple extra restrictions some how. > > Best wishes > > ..Steve > ___ > 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] "too many restrictions" mkgmap message
Hi Steve, I'm getting the error "too many restrictions" when compiling one of my maps with the as you can see in the out put bellow: java -Xmx10g -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar --style-file=..\Ferramentas\mkgmap-style-tracksource --license-file="..\txt\Licenca-TRC.txt" -c TS-Brasil.args Time started: Thu Jul 02 04:30:41 BRT 2015 Bad file format: 90002054.osm.gz too many restrictions Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Thu Jul 02 04:35:14 BRT 2015 Total time taken: 273335ms And I saw in the mkgmap code that this error was thrown in TableC.getOffsetSize method written by you. Could you or anyone tell me what should be wrong in my map to cause this problem? It looks like a specific problem in one of my restrictions. But what kind of problem? I don't know what I must find in the map to fix the problem. Thank you. Best regards. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Numbering loss in the version which came after the r3602
Hi Andrzej, Ok, thank you for your time and analyses. Lets wait for Gerd. regards, Alexandre 2015-06-17 13:13 GMT-03:00 Andrzej Popowski : > Hi Alexandre, > > I confirm, that there is no address on your map with current mkgmap. Data > seems to be OK, so lets wait for Gerd opinion. > > > -- > Best regards, > Andrzej > ___ > 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] Numbering loss in the version which came after the r3602
Hi Andrzej, Our group (http://www.tracksource.org.br) doesn't use OSM data. We draw our maps with other free tools and own development ones and convert the maps to osm format to compile with mkgmap. So you won't find the source data on OSM. However, I prepared a very short map containing only the essential data to simulate the problem. If you compile the attached osm file with r3602 you will see the numbering in street "Rua Porto Alegre". If you compile the same file with r3620 (for example), the street numbers for "Rua Porto Alegre" will be lost. I hope this osm file help you debug and and find the problem. Thanks. Alexandre 2015-06-17 9:11 GMT-03:00 Andrzej Popowski : > Hi Alexandre, > > > You can search for street "Rua Porto Alegre" to see the problem > > what data are you using for compilation? I have tried to find this place > on OSM, I think this is actually Rua Manaus in OSM, with no house numbers: > http://www.openstreetmap.org/way/93121424 > > -- > Best regards, > Andrzej > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > 03205200-vila_velha.osm Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Numbering loss in the version which came after the r3602
Hi Gerd,
Since yesterday we (a group that compiles maps in Brazil) begin to see some
loss of numbers in some of our maps.
As we had never had this problem before, I suspected that the error could
have been introduced in some recent version of mkgmap. So, I restored some
old releases for testing and I found that the numbering were generated
correctly until release 3602 as seen in the image below in the white-box
("390 Rua Porto Alegre"):
*Snapshot taken form MapSource of a map compiled wiht mkgmap r3602*
[image: Imagem inline 1]
Using the same source osm file, the numbering is lost in the street "Rua
Porto Alegre" (for example), if the map is compiled with any newer release
of mkgmap than 3602. The snapshot bellow was taken from a map compiled with
release 3616::
*Snapshot taken form MapSource of a map compiled wiht mkgmap r3616:*
[image: Imagem inline 2]
These compiled maps img are available for tests at the file sharing area:
http://files.mkgmap.org.uk/download/270/03205200_r3602.img
http://files.mkgmap.org.uk/download/271/03205200_r3616.img
You can search for street "Rua Porto Alegre" to see the problem, but it
problem can be found in other places too.
My guess is that the problem arose when housenumber2 brahch was merged to
trunk.
If you need more information, please let me know.
Thank you.
Regards,
Alexandre
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter problem: losing a track segment
Ok Gerd, I'll include this change in the roadmap of my generator. You know as a developer... there are some many things to do in the backlog and our time available is so short! :-) Thanks. Alexandre 2015-06-02 9:34 GMT-03:00 GerdP : > Hi Alexandre, > > well, the advantage of the keep-complete option is that you don't need > the large overlap and still get complete ways and relations, so > it's about disk usage, memory and quality. As long as you files are rather > small > you can probably use a large overlap value instead. > Maybe you can calculate the needed overlap in your generator. > > ciao, > Gerd > > > Alexandre Loss wrote > > Hi Gerd, > > > > I already made a previous analysis before to change my generator. Well, > > it's possible, but I practically have to rebuild the generator entirely. > > So, I understood that you said that it's better solution but not a "must" > > solution to change generator. If so, I will prefer to keep the generator > > this way for a while. > > However, If you think I can be missing something in my maps due this > mixed > > syntax, then I will plan to change my code. > > > > Thanks > > > > Alexandre > > > > 2015-06-02 2:36 GMT-03:00 Gerd Petermann < > > > gpetermann_muenchen@ > > > >: > > > >> Hi Alexandre, > >> > >> the better solution would be to change your generator so that > >> it writes the data in the expected order (nodes, ways, relations, each > >> with > >> ascending ids). If you do that, you can remove the options --mixed and > >> --overlap > >> and use the default --keep-complete=true. > >> > >> A possible compromise: > >> I have to double check that, but I think the keep-complete option only > >> requires that > >> the ids are sorted, it doesn't care about the order of the elements. > >> On the other hand, the xml parser requires the > >> mixed option when the element types are not sorted, > >> and a check prohibtis the combination of --mixed and > keep-complete=true. > >> If I am right, I can remove this check. > >> > >> Ciao, > >> Gerd > >> > >> -- > >> Date: Sat, 30 May 2015 09:15:19 -0300 > >> From: > > > alexandre.loss@ > > >> To: > > > mkgmap-dev@.org > > >> Subject: Re: [mkgmap-dev] Splitter problem: losing a track segment > >> > >> > >> Hi Gerd, > >> > >> Overlap of 1 fixed my problem. :-) > >> > >> Thank you very much! > >> > >> Alexandre > >> > >> 2015-05-30 8:20 GMT-03:00 Alexandre Loss < > > > alexandre.loss@ > > > >: > >> > >> Hi Gerd, > >> > >> Thanks for your answer. > >> I'll try your suggestion and give you a feedback about the result. > >> > >> Regards, > >> > >> Alexandre > >> > >> 2015-05-30 5:43 GMT-03:00 Gerd Petermann < > > > gpetermann_muenchen@ > > > > > >> : > >> > >> Hi Alexandre, > >> > >> I don't have much time to analyse your data today. > >> I think splitter assumes that the tile boundaries > >> are > >> "multiples of 0x200 map units wide and high" > >> when you use resolution=15. > >> > >> Since you use keep-complete=false you have to watch > >> the overlap value. > >> You can use a larger overlap value like 1 to fix this problem. > >> > >> Gerd > >> > >> > >> -- > >> Date: Fri, 29 May 2015 22:04:34 -0300 > >> From: > > > alexandre.loss@ > > >> To: > > > mkgmap-dev@.org > > >> Subject: [mkgmap-dev] Splitter problem: losing a track segment > >> > >> > >> Hi guys, > >> > >> I'm facing a problem in one of my maps, that is probably might be > >> happening in other places where I didn't see yet. > >> The problem can be seen in the figure below taken from MapSource. There > >> is > >> a gap in a track on the border of the tiles: > >> > >> [image: Imagem inline 2] > >> > >> So I started to analyze the problem step-by-step till find that the > >> problem was generated by Splitter (last version). > >> > >> To simplify your analysis, I edited my .osm file before running Splitter >
Re: [mkgmap-dev] Splitter problem: losing a track segment
Hi Gerd, I already made a previous analysis before to change my generator. Well, it's possible, but I practically have to rebuild the generator entirely. So, I understood that you said that it's better solution but not a "must" solution to change generator. If so, I will prefer to keep the generator this way for a while. However, If you think I can be missing something in my maps due this mixed syntax, then I will plan to change my code. Thanks Alexandre 2015-06-02 2:36 GMT-03:00 Gerd Petermann : > Hi Alexandre, > > the better solution would be to change your generator so that > it writes the data in the expected order (nodes, ways, relations, each with > ascending ids). If you do that, you can remove the options --mixed and > --overlap > and use the default --keep-complete=true. > > A possible compromise: > I have to double check that, but I think the keep-complete option only > requires that > the ids are sorted, it doesn't care about the order of the elements. > On the other hand, the xml parser requires the > mixed option when the element types are not sorted, > and a check prohibtis the combination of --mixed and keep-complete=true. > If I am right, I can remove this check. > > Ciao, > Gerd > > -- > Date: Sat, 30 May 2015 09:15:19 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Splitter problem: losing a track segment > > > Hi Gerd, > > Overlap of 1 fixed my problem. :-) > > Thank you very much! > > Alexandre > > 2015-05-30 8:20 GMT-03:00 Alexandre Loss : > > Hi Gerd, > > Thanks for your answer. > I'll try your suggestion and give you a feedback about the result. > > Regards, > > Alexandre > > 2015-05-30 5:43 GMT-03:00 Gerd Petermann > : > > Hi Alexandre, > > I don't have much time to analyse your data today. > I think splitter assumes that the tile boundaries > are > "multiples of 0x200 map units wide and high" > when you use resolution=15. > > Since you use keep-complete=false you have to watch > the overlap value. > You can use a larger overlap value like 1 to fix this problem. > > Gerd > > > -- > Date: Fri, 29 May 2015 22:04:34 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] Splitter problem: losing a track segment > > > Hi guys, > > I'm facing a problem in one of my maps, that is probably might be > happening in other places where I didn't see yet. > The problem can be seen in the figure below taken from MapSource. There is > a gap in a track on the border of the tiles: > > [image: Imagem inline 2] > > So I started to analyze the problem step-by-step till find that the > problem was generated by Splitter (last version). > > To simplify your analysis, I edited my .osm file before running Splitter > and remove all objects (nodes, lines, poi, etc.) not related to the > problem, leaving only the line where the problem happens. The result was > the file "93352150-Ribeirao_Preto.osm" attached, containing only this: > > > > > version="1"/> > version="1"/> > version="1"/> > version="1"/> > > > > > > > > > > > > > > > > Then I ran Splitter on this file and the result was the file > "93352150.osm" (attached and compacted), whose content are the lines bellow: > > > > maxlat='-20.401611328125' maxlon='-47.548828125'/> > > > > > > > > > > > > > > > > > > Note that in the "93352150.osm" file is missing the node 576 definition > (i.e.: version="1"/>). > And this is the cause of the lost segment. > > I'm running Splitter in the following way: > > java -jar splitter.jar --split-file=93352150-Ribeirao_Preto.list > --max-areas=1024 --mixed=true --keep-complete=false --resolution=15 > --output=xml 93352150-Ribeirao_Preto.osm > > The above .list file is attached. > > If this is not a Splitter error, please, let me know what I'm doing wrong. > > Thanks. > > Alexandre > > > ___ 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 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter problem: losing a track segment
Hi Gerd, Overlap of 1 fixed my problem. :-) Thank you very much! Alexandre 2015-05-30 8:20 GMT-03:00 Alexandre Loss : > Hi Gerd, > > Thanks for your answer. > I'll try your suggestion and give you a feedback about the result. > > Regards, > > Alexandre > > 2015-05-30 5:43 GMT-03:00 Gerd Petermann > : > >> Hi Alexandre, >> >> I don't have much time to analyse your data today. >> I think splitter assumes that the tile boundaries >> are >> "multiples of 0x200 map units wide and high" >> when you use resolution=15. >> >> Since you use keep-complete=false you have to watch >> the overlap value. >> You can use a larger overlap value like 1 to fix this problem. >> >> Gerd >> >> >> -- >> Date: Fri, 29 May 2015 22:04:34 -0300 >> From: alexandre.l...@gmail.com >> To: mkgmap-dev@lists.mkgmap.org.uk >> Subject: [mkgmap-dev] Splitter problem: losing a track segment >> >> >> Hi guys, >> >> I'm facing a problem in one of my maps, that is probably might be >> happening in other places where I didn't see yet. >> The problem can be seen in the figure below taken from MapSource. There >> is a gap in a track on the border of the tiles: >> >> [image: Imagem inline 2] >> >> So I started to analyze the problem step-by-step till find that the >> problem was generated by Splitter (last version). >> >> To simplify your analysis, I edited my .osm file before running Splitter >> and remove all objects (nodes, lines, poi, etc.) not related to the >> problem, leaving only the line where the problem happens. The result was >> the file "93352150-Ribeirao_Preto.osm" attached, containing only this: >> >> >> >> >> > version="1"/> >> > version="1"/> >> > version="1"/> >> > version="1"/> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Then I ran Splitter on this file and the result was the file >> "93352150.osm" (attached and compacted), whose content are the lines bellow: >> >> >> >> > maxlat='-20.401611328125' maxlon='-47.548828125'/> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Note that in the "93352150.osm" file is missing the node 576 definition >> (i.e.: > version="1"/>). >> And this is the cause of the lost segment. >> >> I'm running Splitter in the following way: >> >> java -jar splitter.jar --split-file=93352150-Ribeirao_Preto.list >> --max-areas=1024 --mixed=true --keep-complete=false --resolution=15 >> --output=xml 93352150-Ribeirao_Preto.osm >> >> The above .list file is attached. >> >> If this is not a Splitter error, please, let me know what I'm doing wrong. >> >> Thanks. >> >> Alexandre >> >> >> ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter problem: losing a track segment
Hi Gerd, Thanks for your answer. I'll try your suggestion and give you a feedback about the result. Regards, Alexandre 2015-05-30 5:43 GMT-03:00 Gerd Petermann : > Hi Alexandre, > > I don't have much time to analyse your data today. > I think splitter assumes that the tile boundaries > are > "multiples of 0x200 map units wide and high" > when you use resolution=15. > > Since you use keep-complete=false you have to watch > the overlap value. > You can use a larger overlap value like 1 to fix this problem. > > Gerd > > > -- > Date: Fri, 29 May 2015 22:04:34 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] Splitter problem: losing a track segment > > > Hi guys, > > I'm facing a problem in one of my maps, that is probably might be > happening in other places where I didn't see yet. > The problem can be seen in the figure below taken from MapSource. There is > a gap in a track on the border of the tiles: > > [image: Imagem inline 2] > > So I started to analyze the problem step-by-step till find that the > problem was generated by Splitter (last version). > > To simplify your analysis, I edited my .osm file before running Splitter > and remove all objects (nodes, lines, poi, etc.) not related to the > problem, leaving only the line where the problem happens. The result was > the file "93352150-Ribeirao_Preto.osm" attached, containing only this: > > > > > version="1"/> > version="1"/> > version="1"/> > version="1"/> > > > > > > > > > > > > > > > > Then I ran Splitter on this file and the result was the file > "93352150.osm" (attached and compacted), whose content are the lines bellow: > > > > maxlat='-20.401611328125' maxlon='-47.548828125'/> > > > > > > > > > > > > > > > > > > Note that in the "93352150.osm" file is missing the node 576 definition > (i.e.: version="1"/>). > And this is the cause of the lost segment. > > I'm running Splitter in the following way: > > java -jar splitter.jar --split-file=93352150-Ribeirao_Preto.list > --max-areas=1024 --mixed=true --keep-complete=false --resolution=15 > --output=xml 93352150-Ribeirao_Preto.osm > > The above .list file is attached. > > If this is not a Splitter error, please, let me know what I'm doing wrong. > > Thanks. > > Alexandre > > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Splitter problem: losing a track segment
Hi guys, I'm facing a problem in one of my maps, that is probably might be happening in other places where I didn't see yet. The problem can be seen in the figure below taken from MapSource. There is a gap in a track on the border of the tiles: [image: Imagem inline 2] So I started to analyze the problem step-by-step till find that the problem was generated by Splitter (last version). To simplify your analysis, I edited my .osm file before running Splitter and remove all objects (nodes, lines, poi, etc.) not related to the problem, leaving only the line where the problem happens. The result was the file "93352150-Ribeirao_Preto.osm" attached, containing only this: Then I ran Splitter on this file and the result was the file "93352150.osm" (attached and compacted), whose content are the lines bellow: Note that in the "93352150.osm" file is missing the node 576 definition (i.e.: ). And this is the cause of the lost segment. I'm running Splitter in the following way: java -jar splitter.jar --split-file=93352150-Ribeirao_Preto.list --max-areas=1024 --mixed=true --keep-complete=false --resolution=15 --output=xml 93352150-Ribeirao_Preto.osm The above .list file is attached. If this is not a Splitter error, please, let me know what I'm doing wrong. Thanks. Alexandre 93352150-Ribeirao_Preto.osm Description: Binary data 93352150.osm.gz Description: GNU Zip compressed data 93352150-Ribeirao_Preto.list Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing parameters
Hi Dave,
I'm curious about this too and hope the specialist could explain this to us.
Alexandre
2015-05-15 14:45 GMT-03:00 Dave Swarthout :
> I am curious to know how mkgmap handles the display of and text to speech
> aspects of motorway junctions. It's hard to test for this without actually
> creating a route and then driving it to see and hear what the Garmin is
> doing with the data or to discover where it gets the information from.
>
> I'm assuming that whatever one puts in the exit_to=* tag gets displayed
> and spoken by the Garmin "assistant". Does mkgmap ever use the
> destination=* tag, and if so under what circumstances?
>
> I found this rule in the lines style sheet, but I do not understand it
> well enough to help me answer my question
>
> (highway=motorway_link | highway=trunk_link) & mkgmap:exit_hint=true &
> mkgmap:dest_hint=true
> { name '${destination:ref|subst: =>} ${destination|subst:;=> |subst:/=>
> }' |
> '${ref|subst: =>} ${destination|subst:;=> |subst:/=> }' |
> '${destination|subst:;=> |subst:/=> }' |
> 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' |
> highway=road
> 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' |
> 'Exit ${mkgmap:exit_hint_exit_to}' |
> 'Exit ${mkgmap:exit_hint_name}' |
> 'Exit ${mkgmap:exit_hint_ref}'
>}
>
>
> As always, thanks in advance to any help you can provide.
>
> Dave
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
> ___
> 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] address search and road names with refs
The same in Brazil, i.e.: regards, Alexandre 2015-03-20 13:23 GMT-03:00 Carlos Dávila : > El 20/03/15 a las 06:29, Gerd Petermann escribió: > >> in Germany I've never seen or heard an address >> that uses the road ref. >> Within cities the roads all have a sign giving >> a name, the address is written as >> >> >> >> >> In short: >> I don't want to see the ref when I am searching for an address. >> If possible, I want to see it and be able to search for it >> when searching for a road. >> It should also appear when the map is rendered. >> > Same in Spain > > ___ > 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] Fwd: [mkgmap-svn] Commit: r3498: modfiy evaluation of maxspeed=* tag
Ok. Thanks Gerd!
2015-03-18 11:40 GMT-03:00 GerdP :
> Hi Alexandre,
>
> >Are mkgmap:road-speed and mkgmap:road-class still recognized and
> operational?
>
>
> yes, the change was in the default style file inc/roadspeed only.
>
> Gerd
>
>
> Alexandre Loss wrote
> > Hi Gerd,
> >
> > I have rules like these ones below in my "lines" style file:
> > highway=* & vel=* { set mkgmap:road-speed='${vel}' ; delete vel}
> > highway=* & rc=* { set mkgmap:road-class='${rc}' ; delete rc}
> >
> > Do I have to change anything in the style to run release 3498? Are
> > mkgmap:road-speed and mkgmap:road-class still recognized and operational?
> >
> > Thanks.
> >
> > Alexandre
> >
> > -- Forwarded message --
> > From: svn commit <
>
> > svn@.org
>
> > >
> > Date: 2015-03-18 5:13 GMT-03:00
> > Subject: [mkgmap-svn] Commit: r3498: modfiy evaluation of maxspeed=* tag
> > To:
>
> > mkgmap-svn@.org
>
> >
> >
> >
> > Version mkgmap-r3498 was committed by gerd on Wed, 18 Mar 2015
> >
> > modfiy evaluation of maxspeed=* tag
> >
> > - set mkgmap:road-speed-max instead of mkgmap:road-speed-class
> > - evaluate also some tags like maxspeed=RU:urban based on rules
> > documented in the wiki
> > - use slightly different threshold values
> >
> > thanks to Andrzej Popowski and Bernd Weigelt
> > ___
> > mkgmap-svn mailing list
> > To unsubscribe send an mail to
>
> > mkgmap-svn-leave@.org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn
> >
> > ___
> > mkgmap-dev mailing list
>
> > mkgmap-dev@.org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Commit-r3498-modfiy-evaluation-of-maxspeed-tag-tp5837621p5837694.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> 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] Fwd: [mkgmap-svn] Commit: r3498: modfiy evaluation of maxspeed=* tag
Hi Gerd,
I have rules like these ones below in my "lines" style file:
highway=* & vel=* { set mkgmap:road-speed='${vel}' ; delete vel}
highway=* & rc=* { set mkgmap:road-class='${rc}' ; delete rc}
Do I have to change anything in the style to run release 3498? Are
mkgmap:road-speed and mkgmap:road-class still recognized and operational?
Thanks.
Alexandre
-- Forwarded message --
From: svn commit
Date: 2015-03-18 5:13 GMT-03:00
Subject: [mkgmap-svn] Commit: r3498: modfiy evaluation of maxspeed=* tag
To: mkgmap-...@lists.mkgmap.org.uk
Version mkgmap-r3498 was committed by gerd on Wed, 18 Mar 2015
modfiy evaluation of maxspeed=* tag
- set mkgmap:road-speed-max instead of mkgmap:road-speed-class
- evaluate also some tags like maxspeed=RU:urban based on rules
documented in the wiki
- use slightly different threshold values
thanks to Andrzej Popowski and Bernd Weigelt
___
mkgmap-svn mailing list
To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] "Building" POI are not searchable resource
Hi Nick, 2015-03-18 3:41 GMT-03:00 nwillink : > Hi Alexandre, > > No ,they are searchable but the results depend on your location and whether > they are within reach. > Yes, I understand and this is the reason I suspect that there is a mistake, because I am searching just a few meters from the building. Moreover, I able to find buildins using MapSource "Find Near Places" tool, but not using "Find Place-->Resource". > I have found that many with subtypes >&12 are not searchable. > This is one more reason to suspect that is a problem, because I am using the 0x6402 code for "buildings". I.e.: subtype 0x02. Thanks Alexandre > I have created fictitious maps blasting them with POIs to check on their > searchability and compared the results with many topo typ files > > r > > Nick > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/Building-POI-are-not-searchable-resource-tp5837552p5837612.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > ___ > 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] "Building" POI are not searchable resource
Hi Nick, Are you telling me that the man-made codes, 6400 and above, are not searchable in MapSource "Find Place-->Resource" tool? I mean, is this a mkgmap rule? I'm asking because I used to compile my maps with cgpsmapper and this search is allowed there. So, since I'm a mkgmap beginner, I do not know if this is a problem in mkgmap (bug) or conscious decision/rule. Thanks Alexandre 2015-03-17 19:03 GMT-03:00 nwillink : > I'm not so sure mkgmap creates unusual search results, as the behaviour you > describe applies in my experience to TOPO maps as well. > > 6402 like all 6400+ falls under 'man made' - the way they 'appear' differs > depending on whether you are using Mapsource,Basecamp or say the Oregon - > the more recent gps devices feature categories not even listed in Basecamp. > > Often Mapsource gives more results than Basecamp - they are not limited to > a > particular region BUT its categories are more limited. > > r > > Nick > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/Building-POI-are-not-searchable-resource-tp5837552p5837573.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > ___ > 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] "Building" POI are not searchable resource
Hi Gerd, I observed in my maps that the POI of type "building" (Garmin code 0x6402) are not searchable using MapSource "Find Place-->Resource" tool. However, I'm able to find these kind POI using MapSource "Find Near Places" tool. Is this the regular behavior or is there some problem in the index? Thanks. Alexandre ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0"
Ok Steve, However this isn't a serious problem. Since we know the rules, it's just a matter of apply it. Maybe a simple note in the mkgmap documentation is enough to handle of this problem. I mean, this can be treat as a rule than a error. Thank you again by your prompt support and have a nice weekend. Alexandre (Enviado via iPad) > Em 06/03/2015, às 07:37, Steve Ratcliffe escreveu: > > Hi > >> But the must interesting thing is that the order can be ascending or >> descending. Do you confirm that the order doesn't matter since it is >> ordered? > > The maps in the MDR1 section must be in ascending order of map number. > > Mkgmap always sorts them into ascending order and then tries to > renumber all the references to the map tile to match. This sometimes > (or always) fails and is a bug. I don't know what the bug is, so I > suppose that if they are originally sorted in decending order then it > will happen to work. > > ..Steve > ___ > 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] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0"
Hi Steve, Give an error if it is wrong should be a good solution, better than allow install and get a error in MapSource. Anyway, your information was very useful. But the must interesting thing is that the order can be ascending or descending. Do you confirm that the order doesn't matter since it is ordered? Thanks 2015-03-05 19:59 GMT-03:00 Steve Ratcliffe : > On 05/03/15 16:50, Alexandre Loss wrote: > >> The problem was in the ordering of the "input-file" in the "args" file. >> *They need to be sorted in descending order of their size.* >> >> > OK that is helpful - but the order is actually by map number not by size. > > Happens to be the same thing by coincidence in this case :) > > It is the mapnumber that is recorded inside the file, not the > name of the file itself that matter, although that is the > usually the same thing for mkgmap produced maps. > > I did add code so that it didn't matter what order they were given > but recently I found a case where it didn't seem to work and I guess > that this now confirms it. The last fix was in r3211. > > I'm not sure if it is possible to fix it properly or if we are just > going to have to give an error if it is wrong. > > ..Steve > > ___ > 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] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0"
Hi Gerd, Any order produces a installable map for MapSource. However, depending of the order, this map should be or not installed into a GPS. Moreover, I tested the ascending order and it works too. Very strange. Alexandre 2015-03-05 14:27 GMT-03:00 GerdP : > Hi Alexandre, > > I think the information is important, but your args file contains > the max-jobs option, that means the order is also dependend on the number > of processors. > Don't know if Steve needs the info, baybe you can say the order > that doesn't work and one that works (both without the max-jobs option) > > Gerd > > > Alexandre Loss wrote > > Hi guys, > > > > I think I found the problem! > > It seems incredible, but the problem had nothing to do with meaningless > > names or something like that. > > > > The problem was in the ordering of the "input-file" in the "args" file. > > *They > > need to be sorted in descending order of their size.* > > > > I came to this conclusion by experimentation. At least it worked for me. > I > > don't know if it has any theoretical foundation, but I think it is > > important to share this with you. > > > > Thank you. > > > > Alexandre > > > > 2015-03-05 9:32 GMT-03:00 Alexandre Loss < > > > alexandre.loss@ > > > >: > > > >> Hi Gerd and Steve, > >> > >> I removed all meaningless names from the index, removing all mkgmap tag > >> regarding address from these ways. They left to be shown in the > MapSource > >> address searching tool. > >> But error persists. > >> > >> Alexandre > >> > >> 2015-03-05 3:28 GMT-03:00 Gerd Petermann < > > > gpetermann_muenchen@ > > > > > >> : > >> > >> Hi Alexandre, > >>> > >>> I think the message means that mkgmap has created an index that is not > >>> valid, > >>> probably because a limit was reached that mkgmap doesn't know. > >>> > >>> I noticed that your data contains a lot of highways with rather > >>> meaningless names like > >>> "TERRA", "RUA","ESTRADA MUNICIPAL" etc. > >>> > >>> Maybe this is the reason. These names are also causing a long run time > >>> in > >>> the housenumber > >>> processing. > >>> > >>> Gerd > >>> > >>> -- > >>> Date: Wed, 4 Mar 2015 23:32:58 -0300 > >>> From: > > > alexandre.loss@ > > >>> To: > > > mkgmap-dev@.org > > >>> Subject: [mkgmap-dev] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0" > >>> > >>> > >>> Hi Gerd, > >>> > >>> Some of the tiles that I compiled with mkgmap are throw a MapSource > >>> error > >>> "MDR_TRIM_ADDR.CXX-347-6.16.3.0" when I'm trying to send the map to > GPS. > >>> I found an old discussion about this error (i.e: > >>> https://www.mail-archive.com/ > > > mkgmap-dev@.org > > > /msg13038.html) > >>> but it couldn't help me. > >>> > >>> Please, can you give me a help to deal with this problem? > >>> > >>> I uploaded the files at > http://files.mkgmap.org.uk/download/258/trc.zip > >>> and > >>> this is my styles: > >>> http://files.mkgmap.org.uk/download/259/mkgmap-style-tracksource.rar > >>> > >>> And this is the command used to run mkgmap: > >>> java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar ^ > >>> --style-file=..\Ferramentas\mkgmap-style-tracksource ^ > >>> -c TRC-SC.args > >>> > >>> More specifically, I'm getting this error in the tile "94422861.osm.gz" > >>> > >>> Any help will be great. > >>> > >>> Thank you. > >>> > >>> Alexandre > >>> > >>> > >>> > >>> ___ mkgmap-dev mailing list > >>> > > > mkgmap-dev@.org > > >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >>> > >>> ___ > >>> mkgmap-dev mailing list > >>> > > > mkgmap-dev@.org > > >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >>> > >> > >> > > > > ___ > > mkgmap-dev mailing list > > > mkgmap-dev@.org > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/MapSource-error-MDR-TRIM-ADDR-CXX-347-6-16-3-0-tp5835857p5835973.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > ___ > 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] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0"
Hi guys, I think I found the problem! It seems incredible, but the problem had nothing to do with meaningless names or something like that. The problem was in the ordering of the "input-file" in the "args" file. *They need to be sorted in descending order of their size.* I came to this conclusion by experimentation. At least it worked for me. I don't know if it has any theoretical foundation, but I think it is important to share this with you. Thank you. Alexandre 2015-03-05 9:32 GMT-03:00 Alexandre Loss : > Hi Gerd and Steve, > > I removed all meaningless names from the index, removing all mkgmap tag > regarding address from these ways. They left to be shown in the MapSource > address searching tool. > But error persists. > > Alexandre > > 2015-03-05 3:28 GMT-03:00 Gerd Petermann > : > > Hi Alexandre, >> >> I think the message means that mkgmap has created an index that is not >> valid, >> probably because a limit was reached that mkgmap doesn't know. >> >> I noticed that your data contains a lot of highways with rather >> meaningless names like >> "TERRA", "RUA","ESTRADA MUNICIPAL" etc. >> >> Maybe this is the reason. These names are also causing a long run time in >> the housenumber >> processing. >> >> Gerd >> >> -- >> Date: Wed, 4 Mar 2015 23:32:58 -0300 >> From: alexandre.l...@gmail.com >> To: mkgmap-dev@lists.mkgmap.org.uk >> Subject: [mkgmap-dev] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0" >> >> >> Hi Gerd, >> >> Some of the tiles that I compiled with mkgmap are throw a MapSource error >> "MDR_TRIM_ADDR.CXX-347-6.16.3.0" when I'm trying to send the map to GPS. >> I found an old discussion about this error (i.e: >> https://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg13038.html) >> but it couldn't help me. >> >> Please, can you give me a help to deal with this problem? >> >> I uploaded the files at http://files.mkgmap.org.uk/download/258/trc.zip and >> this is my styles: >> http://files.mkgmap.org.uk/download/259/mkgmap-style-tracksource.rar >> >> And this is the command used to run mkgmap: >> java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar ^ >> --style-file=..\Ferramentas\mkgmap-style-tracksource ^ >> -c TRC-SC.args >> >> More specifically, I'm getting this error in the tile "94422861.osm.gz" >> >> Any help will be great. >> >> Thank you. >> >> Alexandre >> >> >> >> ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0"
Hi Gerd and Steve, I removed all meaningless names from the index, removing all mkgmap tag regarding address from these ways. They left to be shown in the MapSource address searching tool. But error persists. Alexandre 2015-03-05 3:28 GMT-03:00 Gerd Petermann : > Hi Alexandre, > > I think the message means that mkgmap has created an index that is not > valid, > probably because a limit was reached that mkgmap doesn't know. > > I noticed that your data contains a lot of highways with rather > meaningless names like > "TERRA", "RUA","ESTRADA MUNICIPAL" etc. > > Maybe this is the reason. These names are also causing a long run time in > the housenumber > processing. > > Gerd > > -- > Date: Wed, 4 Mar 2015 23:32:58 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0" > > > Hi Gerd, > > Some of the tiles that I compiled with mkgmap are throw a MapSource error > "MDR_TRIM_ADDR.CXX-347-6.16.3.0" when I'm trying to send the map to GPS. > I found an old discussion about this error (i.e: > https://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg13038.html) > but it couldn't help me. > > Please, can you give me a help to deal with this problem? > > I uploaded the files at http://files.mkgmap.org.uk/download/258/trc.zip and > this is my styles: > http://files.mkgmap.org.uk/download/259/mkgmap-style-tracksource.rar > > And this is the command used to run mkgmap: > java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar ^ > --style-file=..\Ferramentas\mkgmap-style-tracksource ^ > -c TRC-SC.args > > More specifically, I'm getting this error in the tile "94422861.osm.gz" > > Any help will be great. > > Thank you. > > Alexandre > > > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error in address index
Great Steve! Thanks for the analysis of the MDR_ADDR_TRIM too! Alexandre 2015-03-05 7:27 GMT-03:00 Steve Ratcliffe : > > Hi Gerd > > please check the file >> http://files.mkgmap.org.uk/download/257/63240008.o5m >> >> For some searches I get >> "The selected street is not valid in this map product. Please select a >> different street." >> > > I've downloaded it and looking at it now. I will also look at > the MDR_ADDR_TRIM problem. > > ..Steve > ___ > 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] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0"
Thanks Gerd! I'll try to do a test leaving this meaningless name out of the index. I mean, for example, don't include the tags mkgmap:address in the ways or something like that. Since I'm converting the osm files from gtm (Trackmaker) ones, I can filter this. Thanks, Alexandre (Enviado via iPad) > Em 05/03/2015, às 03:28, Gerd Petermann > escreveu: > > Hi Alexandre, > > I think the message means that mkgmap has created an index that is not valid, > probably because a limit was reached that mkgmap doesn't know. > > I noticed that your data contains a lot of highways with rather meaningless > names like > "TERRA", "RUA","ESTRADA MUNICIPAL" etc. > > Maybe this is the reason. These names are also causing a long run time in the > housenumber > processing. > > Gerd > > Date: Wed, 4 Mar 2015 23:32:58 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0" > > Hi Gerd, > > Some of the tiles that I compiled with mkgmap are throw a MapSource error > "MDR_TRIM_ADDR.CXX-347-6.16.3.0" when I'm trying to send the map to GPS. > I found an old discussion about this error (i.e: > https://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg13038.html) > but it couldn't help me. > > Please, can you give me a help to deal with this problem? > > I uploaded the files at http://files.mkgmap.org.uk/download/258/trc.zip and > this is my styles: > http://files.mkgmap.org.uk/download/259/mkgmap-style-tracksource.rar > > And this is the command used to run mkgmap: > java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar ^ > --style-file=..\Ferramentas\mkgmap-style-tracksource ^ > -c TRC-SC.args > > More specifically, I'm getting this error in the tile "94422861.osm.gz" > > Any help will be great. > > Thank you. > > Alexandre > > > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] MapSource error: "MDR_TRIM_ADDR.CXX-347-6.16.3.0"
Hi Gerd, Some of the tiles that I compiled with mkgmap are throw a MapSource error "MDR_TRIM_ADDR.CXX-347-6.16.3.0" when I'm trying to send the map to GPS. I found an old discussion about this error (i.e: https://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg13038.html) but it couldn't help me. Please, can you give me a help to deal with this problem? I uploaded the files at http://files.mkgmap.org.uk/download/258/trc.zip and this is my styles: http://files.mkgmap.org.uk/download/259/mkgmap-style-tracksource.rar And this is the command used to run mkgmap: java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar ^ --style-file=..\Ferramentas\mkgmap-style-tracksource ^ -c TRC-SC.args More specifically, I'm getting this error in the tile "94422861.osm.gz" Any help will be great. Thank you. Alexandre ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error in address index
Hi Gerd, I had this problem yesterday, but in my case was the lack of the tag mkgmap:city on the way in question. The behavior was exactly what you described. Alexandre 2015-03-04 8:01 GMT-03:00 Gerd Petermann : > Hi Steve, > > please check the file > http://files.mkgmap.org.uk/download/257/63240008.o5m > > > > For some searches I get > "The selected street is not valid in this map product. Please select a > different street." > > with the trunk version. > > Sample1: > Street: Alleestrasse (L 29) > City: Putbus > > If I leave City empty the search finds the street in Putbus. > > Sample2: > Street: Ackerweg (K 3) > City: > result: error > If I fill the City field: > City: Saal > the search works. > > My options: > java -jar d:\mkgmap-tr\dist\mkgmap_r3487.jar --x-split-name-index > --housenumbers --route --bounds=bounds.zip --index --nsis 63240008.o5m > > Gerd > > ___ > 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] open issues in the housenumber2 branch
Hi Gerd, I agree with you that the trunk approach is the better solution. I think that the second case is difficult to develop and maintain and adds little value in terms of navigation. Alexandre 2015-03-01 5:42 GMT-03:00 Gerd Petermann : > Hi all, > > during the last days I've analysed the reasons for the error messages > reported > by some of you. I came to the conclusion that I have to > - change the handling of addr:interpolation ways completely > - add code to detect the "random number" case earlier and - if detected - > use different methods to split the number intervals > > Both are rather complex changes, so I'll need a few days to code this. > > One open question for you: > How should we handle "missing" information? > If mkgmap finds the numbers 1,3,9,11,17 in that order on the left side > of a road called ABC, it can create different housenumber informations. > One could be like "odd numbers from 1 to 17 on the left", > another could be a more complex sequence > 1) "odd numbers from 1 to 3 on the left", > 2)"odd numbers from 9 to 11 on the left", > 3) "odd number 17 on the left" > A search for ABC 5 would either show a point between 3 and 9 > or two entries with the numbers 3 and 9. > The latter tells you that OSM probably doesn't contain the > exact information and let's you decide where to search for ABC 5. > > The trunk version tends to the simple info, while r3486 > is more likely to produce the complex one. > I think trunk is better here, the complex case should only > occur if the "random number" case was detected. > > Do you agree? > > Gerd > > > ___ > 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] Complex ocean polygon hiding the islands
Gerg, Once again, thank you very much for you prompt, super detailed, complete and instructive answer. Best regards, Alexandre 2015-02-28 4:45 GMT-03:00 Gerd Petermann : > Hi Alexandre, > > yes, simplification happens in various places. The reasons are limits in > the Garmin > format as well as optimization of the img file size. > > 1) The Garmin img format uses a raster with ~2.3 m distance at resolution > 24. > I think of it as a bed of nails, you can draw straigt lines between any of > the nails. > Details below this resolution are removed. We use two different algos for > lines and shapes > here, so expect slightly different results for outlines. > 2) The Garmin format doesn't allow a single polygon with more than 255 > points, so mkgmap > has to split a complex polygon into smaller pieces. > 3) For lower resolutions, the raster is less precise, means, for 23 points > are ~4.6m, 22 -> ~9.6m and > so on. > 4) For lower resolutions, a variant of the Douglas-Peucker-Algo is used to > reduce the img size. > You can change the effect of this by using the "Optimization options": > http://www.mkgmap.org.uk/doc/options > > See also > > http://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm > > Gerd > > -- > Date: Sat, 28 Feb 2015 01:33:18 -0300 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] Complex ocean polygon hiding the islands > > > Hi guys, > > Please see if any of you can help me ... > > I have an ocean polygon with multiple edges and in the middle of these > there are several islands that are in fact holes in the polygon. > Here's an example: > > [image: Imagem inline 1] > > Showing only the contour lines, the polygon is drawn as follows: > > > [image: Imagem inline 2] > Zooming... > [image: Imagem inline 3] > > When I compile the map, the islands/holes are overlapped by the sea. > I noticed that when the polygon is less complex, this overlapping > phenomena doesn't happens. Its looks like mkgmap simplifies complex > polygons. > > Is there any option that I can use in mkgmap to respect the layout of > complex ocean polygons? > > By the way, if this isn't the right list to ask this kind of question, > please let me know cause I'm new here. > > Thanks. > > Alexandre > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Complex ocean polygon hiding the islands
Hi guys, Please see if any of you can help me ... I have an ocean polygon with multiple edges and in the middle of these there are several islands that are in fact holes in the polygon. Here's an example: [image: Imagem inline 1] Showing only the contour lines, the polygon is drawn as follows: [image: Imagem inline 2] Zooming... [image: Imagem inline 3] When I compile the map, the islands/holes are overlapped by the sea. I noticed that when the polygon is less complex, this overlapping phenomena doesn't happens. Its looks like mkgmap simplifies complex polygons. Is there any option that I can use in mkgmap to respect the layout of complex ocean polygons? By the way, if this isn't the right list to ask this kind of question, please let me know cause I'm new here. Thanks. Alexandre ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing across tiles is not working...
Thanks Gerd! 2015-02-24 7:44 GMT-03:00 GerdP : > Hi Alexandre, > > thanks for the feedback. > Reg. housenumber2 branch see this thread > > http://gis.19327.n5.nabble.com/Issues-with-housenumbers-tp5829402.html > > Gerd > > > Alexandre Loss wrote > > Hi Gerd, > > > > Writing to tell you that your tips to sort the osm file solve my problem. > > Thank you very much again. By the way, opportunely, what is the > > housenumber2 branch? I'm new in this group and missed the discussion > > beginning. > > > > Thanks, > > > > Alexandre > > > > (Enviado via iPad) > > > >> Em 18/02/2015, às 17:37, GerdP < > > > gpetermann_muenchen@ > > > > escreveu: > >> > >> Hi Alexandre, > >> > >> good to hear :-) > >> > >> The program XML parser in splitter is not doing many checks, so maybe > you > >> should > >> use another tool to verify the content of the generated file first. > >> > >> Gerd > >> > >> > >> Alexandre Loss wrote > >>> Hi Gerd, > >>> > >>> It works with options --mixed and --keep-complete=false. > >>> > >>> What a valuable tips you gave me! > >>> > >>> In fact MG.osm was generated by a converter which I'm building to > >>> convert > >>> PFM files to OSM, so we can explore all mkgmap + style power. But I > >>> didn't > >>> know about these sort rules. I will change my code to implement this to > >>> see > >>> what happens. > >>> > >>> Thank you so much. You really was very helpful. > >>> > >>> Alexandre > >>> > >>> > >>> 2015-02-18 15:07 GMT-02:00 Gerd Petermann < > >> > >>> gpetermann_muenchen@ > >> > >>> >: > >>> > >>>> Hi Alexandre, > >>>> > >>>> another option is to use options --mixed and --keep-complete=false in > >>>> splitter, e.g. > >>>> > >>>> java -Xmx3G -jar d:\splitter\dist\splitter.jar --num-tiles=6 --mixed > >>>> --keep-complete=false MG.osm > splitter.log > >>>> > >>>> Gerd > >>>> > >>>> -- > >>>> Date: Wed, 18 Feb 2015 13:16:01 -0200 > >>>> From: > >> > >>> alexandre.loss@ > >> > >>>> To: > >> > >>> mkgmap-dev@.org > >> > >>>> Subject: Re: [mkgmap-dev] Routing across tiles is not working... > >>>> > >>>> > >>>> Gerd, > >>>> > >>>> Complementing the information, the versions used are: > >>>> - splitter: 421 compiled 2015-01-10T20:01:10+ > >>>> - mkgmap: 3449 > >>>> > >>>> 2015-02-18 13:09 GMT-02:00 Alexandre Loss < > >> > >>> alexandre.loss@ > >> > >>> >: > >>>> > >>>> Hi Gerd, > >>>> > >>>> Following more information about my compilation: > >>>> > >>>> 1. Splitter command: java -jar ../ferramentas/splitter.jar > >>>> --num-tiles=6 > >>>> MG.osm > >>>> > >>>> 2. mkgmap command: > >>>> java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar > >>>> --x-split-name-index > >>>> --style-file=..\Ferramentas\mkgmap-style-tracksource > >>>> -c MG.args > >>>> > >>>> 3. The files "MG.osm", "MG.args" and styles a compacted in > >>>> http://files.mkgmap.org.uk/download/253/MG.rar. > >>>> > >>>> If you need more information, please let me know. > >>>> > >>>> Thanks. > >>>> > >>>> Alexandre > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2015-02-18 10:31 GMT-02:00 Alexandre Loss < > >> > >>> alexandre.loss@ > >> > >>> >: > >>>> > >>>> Hi Gerd, > >>>> > >>>> I'm out of my desk now, but I will provide all information as soon I > >>>> return home. > >>>> Thanks you for promptly answer my question. >
Re: [mkgmap-dev] Routing across tiles is not working...
Hi Gerd, Writing to tell you that your tips to sort the osm file solve my problem. Thank you very much again. By the way, opportunely, what is the housenumber2 branch? I'm new in this group and missed the discussion beginning. Thanks, Alexandre (Enviado via iPad) > Em 18/02/2015, às 17:37, GerdP escreveu: > > Hi Alexandre, > > good to hear :-) > > The program XML parser in splitter is not doing many checks, so maybe you > should > use another tool to verify the content of the generated file first. > > Gerd > > > Alexandre Loss wrote >> Hi Gerd, >> >> It works with options --mixed and --keep-complete=false. >> >> What a valuable tips you gave me! >> >> In fact MG.osm was generated by a converter which I'm building to convert >> PFM files to OSM, so we can explore all mkgmap + style power. But I didn't >> know about these sort rules. I will change my code to implement this to >> see >> what happens. >> >> Thank you so much. You really was very helpful. >> >> Alexandre >> >> >> 2015-02-18 15:07 GMT-02:00 Gerd Petermann < > >> gpetermann_muenchen@ > >> >: >> >>> Hi Alexandre, >>> >>> another option is to use options --mixed and --keep-complete=false in >>> splitter, e.g. >>> >>> java -Xmx3G -jar d:\splitter\dist\splitter.jar --num-tiles=6 --mixed >>> --keep-complete=false MG.osm > splitter.log >>> >>> Gerd >>> >>> -- >>> Date: Wed, 18 Feb 2015 13:16:01 -0200 >>> From: > >> alexandre.loss@ > >>> To: > >> mkgmap-dev@.org > >>> Subject: Re: [mkgmap-dev] Routing across tiles is not working... >>> >>> >>> Gerd, >>> >>> Complementing the information, the versions used are: >>> - splitter: 421 compiled 2015-01-10T20:01:10+ >>> - mkgmap: 3449 >>> >>> 2015-02-18 13:09 GMT-02:00 Alexandre Loss < > >> alexandre.loss@ > >> >: >>> >>> Hi Gerd, >>> >>> Following more information about my compilation: >>> >>> 1. Splitter command: java -jar ../ferramentas/splitter.jar --num-tiles=6 >>> MG.osm >>> >>> 2. mkgmap command: >>> java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar >>> --x-split-name-index --style-file=..\Ferramentas\mkgmap-style-tracksource >>> -c MG.args >>> >>> 3. The files "MG.osm", "MG.args" and styles a compacted in >>> http://files.mkgmap.org.uk/download/253/MG.rar. >>> >>> If you need more information, please let me know. >>> >>> Thanks. >>> >>> Alexandre >>> >>> >>> >>> >>> >>> >>> >>> 2015-02-18 10:31 GMT-02:00 Alexandre Loss < > >> alexandre.loss@ > >> >: >>> >>> Hi Gerd, >>> >>> I'm out of my desk now, but I will provide all information as soon I >>> return home. >>> Thanks you for promptly answer my question. >>> >>> Alexandre >>> >>> (Enviado via iPad) >>> >>>> Em 18/02/2015, às 10:03, GerdP < > >> gpetermann_muenchen@ > >> > >>> escreveu: >>>> >>>> Hi Alexandre, >>>> >>>> I assume you use the latest trunk versions of splitter and mkgmap >>>> and the routing problem occurs only at the tile borders? >>>> >>>> It is difficult to say what's going wrong without any hints about the >>>> data you use and the program options for splitter and mkgmap. >>>> Please try to report these details so that we can try to reproduce the >>>> problem. >>>> If you can't reproduce the problem with the default style, >>>> please post also a link to your style files, e.g. here: >>>> http://files.mkgmap.org.uk/ >>>> >>>> Gerd >>>> >>>> >>>> Alexandre Loss wrote >>>>> Hi guys, >>>>> >>>>> Maybe my question is basic, but I've researched ever manual, websites >>> and >>>>> blogs searching a solution and have not found. Therefore, you are my >>> last >>>>> hope. >>>>> I am partitioning a map with slplitter using the parameter "num-tiles" >>> and >>>>
Re: [mkgmap-dev] Routing across tiles is not working...
Hi Gerd, It works with options --mixed and --keep-complete=false. What a valuable tips you gave me! In fact MG.osm was generated by a converter which I'm building to convert PFM files to OSM, so we can explore all mkgmap + style power. But I didn't know about these sort rules. I will change my code to implement this to see what happens. Thank you so much. You really was very helpful. Alexandre 2015-02-18 15:07 GMT-02:00 Gerd Petermann : > Hi Alexandre, > > another option is to use options --mixed and --keep-complete=false in > splitter, e.g. > > java -Xmx3G -jar d:\splitter\dist\splitter.jar --num-tiles=6 --mixed > --keep-complete=false MG.osm > splitter.log > > Gerd > > -- > Date: Wed, 18 Feb 2015 13:16:01 -0200 > From: alexandre.l...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Routing across tiles is not working... > > > Gerd, > > Complementing the information, the versions used are: > - splitter: 421 compiled 2015-01-10T20:01:10+ > - mkgmap: 3449 > > 2015-02-18 13:09 GMT-02:00 Alexandre Loss : > > Hi Gerd, > > Following more information about my compilation: > > 1. Splitter command: java -jar ../ferramentas/splitter.jar --num-tiles=6 > MG.osm > > 2. mkgmap command: > java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar > --x-split-name-index --style-file=..\Ferramentas\mkgmap-style-tracksource > -c MG.args > > 3. The files "MG.osm", "MG.args" and styles a compacted in > http://files.mkgmap.org.uk/download/253/MG.rar. > > If you need more information, please let me know. > > Thanks. > > Alexandre > > > > > > > > 2015-02-18 10:31 GMT-02:00 Alexandre Loss : > > Hi Gerd, > > I'm out of my desk now, but I will provide all information as soon I > return home. > Thanks you for promptly answer my question. > > Alexandre > > (Enviado via iPad) > > > Em 18/02/2015, às 10:03, GerdP > escreveu: > > > > Hi Alexandre, > > > > I assume you use the latest trunk versions of splitter and mkgmap > > and the routing problem occurs only at the tile borders? > > > > It is difficult to say what's going wrong without any hints about the > > data you use and the program options for splitter and mkgmap. > > Please try to report these details so that we can try to reproduce the > > problem. > > If you can't reproduce the problem with the default style, > > please post also a link to your style files, e.g. here: > > http://files.mkgmap.org.uk/ > > > > Gerd > > > > > > Alexandre Loss wrote > >> Hi guys, > >> > >> Maybe my question is basic, but I've researched ever manual, websites > and > >> blogs searching a solution and have not found. Therefore, you are my > last > >> hope. > >> I am partitioning a map with slplitter using the parameter "num-tiles" > and > >> then compiling the generated tiles with mkgmap. The problem is that in > >> MapSource I can not route between the tiles. > >> It seems that the majority of ways bordering had their last node (bound) > >> removed in splitter processing. See image below: > >> > >> > >> [image: Imagem inline 1] > >> > >> And in the rare cases where there is continuity at the border, the > routing > >> is not working: > >> > >> > >> > >> [image: Imagem inline 2] > >> > >> Please help! What am I doing wrong? > >> > >> Thank you! > >> > >> Regards, > >> > >> Alexandre > >> > >> ___ > >> mkgmap-dev mailing list > > > >> mkgmap-dev@.org > > > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >> > >> image.png (18K) > >> <http://gis.19327.n5.nabble.com/attachment/5834064/0/image.png>; > >> image.png (74K) > >> <http://gis.19327.n5.nabble.com/attachment/5834064/1/image.png>; > > > > > > > > > > > > -- > > View this message in context: > http://gis.19327.n5.nabble.com/Routing-across-tiles-is-not-working-tp5834064p5834076.html > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > ___ > > 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 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] Routing across tiles is not working...
Gerd, Complementing the information, the versions used are: - splitter: 421 compiled 2015-01-10T20:01:10+ - mkgmap: 3449 2015-02-18 13:09 GMT-02:00 Alexandre Loss : > Hi Gerd, > > Following more information about my compilation: > > 1. Splitter command: java -jar ../ferramentas/splitter.jar --num-tiles=6 > MG.osm > > 2. mkgmap command: > java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar > --x-split-name-index --style-file=..\Ferramentas\mkgmap-style-tracksource > -c MG.args > > 3. The files "MG.osm", "MG.args" and styles a compacted in > http://files.mkgmap.org.uk/download/253/MG.rar. > > If you need more information, please let me know. > > Thanks. > > Alexandre > > > > > > > > 2015-02-18 10:31 GMT-02:00 Alexandre Loss : > > Hi Gerd, >> >> I'm out of my desk now, but I will provide all information as soon I >> return home. >> Thanks you for promptly answer my question. >> >> Alexandre >> >> (Enviado via iPad) >> >> > Em 18/02/2015, às 10:03, GerdP >> escreveu: >> > >> > Hi Alexandre, >> > >> > I assume you use the latest trunk versions of splitter and mkgmap >> > and the routing problem occurs only at the tile borders? >> > >> > It is difficult to say what's going wrong without any hints about the >> > data you use and the program options for splitter and mkgmap. >> > Please try to report these details so that we can try to reproduce the >> > problem. >> > If you can't reproduce the problem with the default style, >> > please post also a link to your style files, e.g. here: >> > http://files.mkgmap.org.uk/ >> > >> > Gerd >> > >> > >> > Alexandre Loss wrote >> >> Hi guys, >> >> >> >> Maybe my question is basic, but I've researched ever manual, websites >> and >> >> blogs searching a solution and have not found. Therefore, you are my >> last >> >> hope. >> >> I am partitioning a map with slplitter using the parameter "num-tiles" >> and >> >> then compiling the generated tiles with mkgmap. The problem is that in >> >> MapSource I can not route between the tiles. >> >> It seems that the majority of ways bordering had their last node >> (bound) >> >> removed in splitter processing. See image below: >> >> >> >> >> >> [image: Imagem inline 1] >> >> >> >> And in the rare cases where there is continuity at the border, the >> routing >> >> is not working: >> >> >> >> >> >> >> >> [image: Imagem inline 2] >> >> >> >> Please help! What am I doing wrong? >> >> >> >> Thank you! >> >> >> >> Regards, >> >> >> >> Alexandre >> >> >> >> ___ >> >> mkgmap-dev mailing list >> > >> >> mkgmap-dev@.org >> > >> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> >> image.png (18K) >> >> <http://gis.19327.n5.nabble.com/attachment/5834064/0/image.png>; >> >> image.png (74K) >> >> <http://gis.19327.n5.nabble.com/attachment/5834064/1/image.png>; >> > >> > >> > >> > >> > >> > -- >> > View this message in context: >> http://gis.19327.n5.nabble.com/Routing-across-tiles-is-not-working-tp5834064p5834076.html >> > Sent from the Mkgmap Development mailing list archive at Nabble.com. >> > ___ >> > 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] Routing across tiles is not working...
Hi Gerd, Following more information about my compilation: 1. Splitter command: java -jar ../ferramentas/splitter.jar --num-tiles=6 MG.osm 2. mkgmap command: java -Xmx4096m -XX:+UseConcMarkSweepGC -jar ..\Ferramentas\mkgmap.jar --x-split-name-index --style-file=..\Ferramentas\mkgmap-style-tracksource -c MG.args 3. The files "MG.osm", "MG.args" and styles a compacted in http://files.mkgmap.org.uk/download/253/MG.rar. If you need more information, please let me know. Thanks. Alexandre 2015-02-18 10:31 GMT-02:00 Alexandre Loss : > Hi Gerd, > > I'm out of my desk now, but I will provide all information as soon I > return home. > Thanks you for promptly answer my question. > > Alexandre > > (Enviado via iPad) > > > Em 18/02/2015, às 10:03, GerdP > escreveu: > > > > Hi Alexandre, > > > > I assume you use the latest trunk versions of splitter and mkgmap > > and the routing problem occurs only at the tile borders? > > > > It is difficult to say what's going wrong without any hints about the > > data you use and the program options for splitter and mkgmap. > > Please try to report these details so that we can try to reproduce the > > problem. > > If you can't reproduce the problem with the default style, > > please post also a link to your style files, e.g. here: > > http://files.mkgmap.org.uk/ > > > > Gerd > > > > > > Alexandre Loss wrote > >> Hi guys, > >> > >> Maybe my question is basic, but I've researched ever manual, websites > and > >> blogs searching a solution and have not found. Therefore, you are my > last > >> hope. > >> I am partitioning a map with slplitter using the parameter "num-tiles" > and > >> then compiling the generated tiles with mkgmap. The problem is that in > >> MapSource I can not route between the tiles. > >> It seems that the majority of ways bordering had their last node (bound) > >> removed in splitter processing. See image below: > >> > >> > >> [image: Imagem inline 1] > >> > >> And in the rare cases where there is continuity at the border, the > routing > >> is not working: > >> > >> > >> > >> [image: Imagem inline 2] > >> > >> Please help! What am I doing wrong? > >> > >> Thank you! > >> > >> Regards, > >> > >> Alexandre > >> > >> ___ > >> mkgmap-dev mailing list > > > >> mkgmap-dev@.org > > > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >> > >> image.png (18K) > >> <http://gis.19327.n5.nabble.com/attachment/5834064/0/image.png>; > >> image.png (74K) > >> <http://gis.19327.n5.nabble.com/attachment/5834064/1/image.png>; > > > > > > > > > > > > -- > > View this message in context: > http://gis.19327.n5.nabble.com/Routing-across-tiles-is-not-working-tp5834064p5834076.html > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > ___ > > 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] Routing across tiles is not working...
Hi Gerd, I'm out of my desk now, but I will provide all information as soon I return home. Thanks you for promptly answer my question. Alexandre (Enviado via iPad) > Em 18/02/2015, às 10:03, GerdP escreveu: > > Hi Alexandre, > > I assume you use the latest trunk versions of splitter and mkgmap > and the routing problem occurs only at the tile borders? > > It is difficult to say what's going wrong without any hints about the > data you use and the program options for splitter and mkgmap. > Please try to report these details so that we can try to reproduce the > problem. > If you can't reproduce the problem with the default style, > please post also a link to your style files, e.g. here: > http://files.mkgmap.org.uk/ > > Gerd > > > Alexandre Loss wrote >> Hi guys, >> >> Maybe my question is basic, but I've researched ever manual, websites and >> blogs searching a solution and have not found. Therefore, you are my last >> hope. >> I am partitioning a map with slplitter using the parameter "num-tiles" and >> then compiling the generated tiles with mkgmap. The problem is that in >> MapSource I can not route between the tiles. >> It seems that the majority of ways bordering had their last node (bound) >> removed in splitter processing. See image below: >> >> >> [image: Imagem inline 1] >> >> And in the rare cases where there is continuity at the border, the routing >> is not working: >> >> >> >> [image: Imagem inline 2] >> >> Please help! What am I doing wrong? >> >> Thank you! >> >> Regards, >> >> Alexandre >> >> ___ >> mkgmap-dev mailing list > >> mkgmap-dev@.org > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> image.png (18K) >> <http://gis.19327.n5.nabble.com/attachment/5834064/0/image.png>; >> image.png (74K) >> <http://gis.19327.n5.nabble.com/attachment/5834064/1/image.png>; > > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/Routing-across-tiles-is-not-working-tp5834064p5834076.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > ___ > 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] Routing across tiles is not working...
Hi guys, Maybe my question is basic, but I've researched ever manual, websites and blogs searching a solution and have not found. Therefore, you are my last hope. I am partitioning a map with slplitter using the parameter "num-tiles" and then compiling the generated tiles with mkgmap. The problem is that in MapSource I can not route between the tiles. It seems that the majority of ways bordering had their last node (bound) removed in splitter processing. See image below: [image: Imagem inline 1] And in the rare cases where there is continuity at the border, the routing is not working: [image: Imagem inline 2] Please help! What am I doing wrong? Thank you! Regards, Alexandre ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mixed index branch merge
Hi guys, The stopwords are very important for Brazilian's maps, because more than 90% of our street names are prefixed with its kind. Examples: Rua Paris, Avenida Antônio de Castro, Avenida Afonso Pena, etc. Avenida (avenue), Rua (road), etc are prefixes. These prefixes will be included in the index increasing its size unnecessarily. I believe that you don't need to care about the country where maps will be compiled. Firstly, because it will be very difficult to identify, understand and apply the particular rules for every country. Moreover, you will expend too much time creating these rules and the users will lost flexibility to the define their own stopwords. So, my suggestion is exactly that: allow the users to define their own stopwords. It should be developed a feature in mkgmap allowing the users to pass the stopwords throw a new parameter/file, for example: --index_stopwords=file.csv file.csv example: "rua","avenida", "tie", "katu", "polku", "kuja" mkgmap must ignore case. That's it. Regards, Alexandre 2015-02-14 5:50 GMT-02:00 Marko Mäkelä : > On Thu, Feb 12, 2015 at 01:24:29PM +, Steve Ratcliffe wrote: > >> So finally I will merge the mixed index branch. >> > > I believe that the database terminology for this is 'inverted index' or > 'fulltext index'. > > I think it would be best to selectively enable it per country along with >> lists of names to avoid. This would be best done by people from or familiar >> with the countries in question. >> > > In fulltext search, these are called 'stopwords'. > > It might not be necessary to do anything to for countries where street > names are commonly written as a single word. Example: "Main Street" would > be "Hauptstrasse" in German, "Huvudgatan" in Sweden and "Päätie" in > Finnish. Only if the first part of the street name is a proper name such as > a person's name, the second part could be written as a separate word, > separated by a space or dash. > > That said, I guess it would still make sense to introduce some stopwords. > Words that I can think of: > > Swedish: gata, gatan, gränd, gränden, stig, stigen, (stråk, stråket) > Finnish: tie, katu, polku, kuja, (raitti, taival) > German: Straße, Strasse, Weg, Allee, Chaussee > Estonian: mnt, maantee, tn, tänav, pst, puiestee > > In Estonia, it seems to be common to write the tn, mnt or pst as a > separate word. > > I could be missing some stopwords in Estonian and for German-speaking > countries. Also, it could be that the French loan words Allee and Chaussee > are sometimes accented. > > The Finnish and Swedish words that I have put in parenthesis should be > very rare, typically used for ways for non-motorized traffic. I don't > think that including them would pollute the index much. You might in fact > want to search for such a name when you are looking for a nice walking or > cycling route (i.e., you expect there to exist some > random-famous-person-name-stråket, but you do not know the random name). > > Marko > ___ > 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
