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
nn <gpetermann_muenc...@hotmail.com>:
> Hi Alexandre,
>
> please read the comment in the link, the tag is used to improve long
> distance routing.
>
> Gerd
> ____
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> i
map-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Alexandre Loss <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 discussi
ot;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
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
I agree!
2017-06-14 15:58 GMT-03:00 Carlos Dávila <cdavi...@orangecorreo.es>:
> 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
ot;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 starte
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 ",
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
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
act 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 <mkgmap-dev
rces
>
> Gerd
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Carlos Dávila <cdavi...@orangecorreo.es>
> Gesendet: Sonntag, 11. Juni 2017 15:32
> An: Development list for mkgmap
> Betreff: Re:
_
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd
> Petermann <gpetermann_muenc...@hotmail.com>
> Gesendet: Mittwoch, 31. Mai 2017 18:35:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Please check if help is o
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
n: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Alexandre Loss <alexandre.l...@gmail.com>
> Gesendet: Dienstag, 4. April 2017 01:41:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Routing problem after mkgmap r3757
>
> Hi A
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 <po...@poczta.onet.pl>:
> Hi,
>
> I just have uploaded example of wrong routing in BaseCamp, onl
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
Hi Patrik,
Convert the license file to UTF-8 solve the problem!
Thanks!
Alexandre
2016-12-20 12:57 GMT-02:00 Alexandre Loss <alexandre.l...@gmail.com>:
> Hi Patrik,
>
> I'll try and post here the result.
>
> Thanks!
>
> Alexandre
>
> 2016-12-20 12:29 GMT-
s
> Patrik
>
> *Gesendet:* Dienstag, 20. Dezember 2016 um 15:22 Uhr
> *Von:* "Alexandre Loss" <alexandre.l...@gmail.com>
> *An:* "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk>
> *Betreff:* [mkgmap-dev] Error reading license-f
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 o
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
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
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
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 <s...@mkgmap.org.uk> escreveu:
>
> Version display-r460 was committed by gerd on Sat, 09 Apr 2016
>
> Don't try to
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.
>
hanks 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 <mkgmap-dev-boun...@lists.mkgmap.org.
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
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
it 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.u
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
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>
> *Gesende
d 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 Alexan
at 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 <
>
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
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 <elib...@gma
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
>
>
> --
>
gt; 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 wil
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
&
Hi Gerd,
It works like a charm!
Thanks!
Regards,
Alexandre
2015-10-15 10:15 GMT-03:00 Alexandre Loss <alexandre.l...@gmail.com>:
> Thanks Gerd!
>
> I saw you committed v3644 with this patch. I will test later and give you
> a feedback.
>
> Regards,
>
> Alexandre
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.
again for your attention and analysis.
Best regards,
Alexandre Loss
2015-07-21 9:06 GMT-03:00 Alexandre Loss alexandre.l...@gmail.com:
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
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 alexandre.l...@gmail.com:
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
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
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.
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
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 po...@poczta.onet.pl:
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
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
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
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
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_muenc...@hotmail.com:
Hi Alexandre,
I don't have much time to analyse your data today.
I think splitter assumes that
Hi Gerd,
Overlap of 1 fixed my problem. :-)
Thank you very much!
Alexandre
2015-05-30 8:20 GMT-03:00 Alexandre Loss alexandre.l...@gmail.com:
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
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
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 daveswarth...@gmail.com:
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
The same in Brazil, i.e.:
street namehouse number
zip codecity nameregion name
regards,
Alexandre
2015-03-20 13:23 GMT-03:00 Carlos Dávila cdavi...@orangecorreo.es:
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.
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
Ok. Thanks Gerd!
2015-03-18 11:40 GMT-03:00 GerdP gpetermann_muenc...@hotmail.com:
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
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
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?
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
it is ordered?
Thanks
2015-03-05 19:59 GMT-03:00 Steve Ratcliffe st...@parabola.me.uk:
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
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.l...@gmail.com:
Hi Gerd and Steve,
I removed all meaningless names from
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
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_muenc...@hotmail.com:
Great Steve!
Thanks for the analysis of the MDR_ADDR_TRIM too!
Alexandre
2015-03-05 7:27 GMT-03:00 Steve Ratcliffe st...@parabola.me.uk:
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
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 gpetermann_muenc...@hotmail.com:
Hi Steve,
please check the file
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 gpetermann_muenc...@hotmail.com:
Hi all,
during the
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 gpetermann_muenc...@hotmail.com:
Hi Alexandre,
yes, simplification happens in various places. The reasons are limits in
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:
, GerdP gpetermann_muenc...@hotmail.com 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
Thanks Gerd!
2015-02-24 7:44 GMT-03:00 GerdP gpetermann_muenc...@hotmail.com:
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
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 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.l...@gmail.com:
Hi Gerd,
Following more information about my compilation:
1. Splitter command
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
-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.l...@gmail.com:
Hi Gerd,
I'm out of my desk
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.l...@gmail.com:
Hi Gerd,
Following more information about my compilation:
1. Splitter command: java -jar
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
76 matches
Mail list logo