A year ago I have looked through the sources. The navi application is
not contained in it, as it is not open source and there are no needs in
making the sources public. In the archive there was only the GPL parts
of the linux base system contained. I think, this has not changed today.
available at all. In the UAE, for instance, there is no formal,
systematic address system *whatsoever* (it is completely normal here
to give your home location relative to local landmarks such as parks,
mosques and malls, rather than giving an address. Makes getting home
deliveries a
Do you have a short draft how you want to detect that two areas are
touching?
When two nodes follwing each other from one polygon are inside the other. Or
on the outline of it.
Yeah, and you will have to test some 100 thousands of nodes, if they lie
inside one of a 10 thousands polygons.
@Markus:
Are there any signs, that the destination road is a oneway?
The destination i want to get routed to is about at the point
http://www.openstreetmap.org/browse/node/1079735170
So it is not a oneway.
I was just right now by foot out at the place with the Garmin Dakota
to
In this situation my Garmin Dakota 20 is routing me up the oneway part
several roads around the block to get to the target just down the
street.
Could it be that we are incorrectly merging the oneway street with the
non-oneway street, making the non-oneway section oneway? What are the
Also, if I'm not sure whether it is called Avenida de la
Libertad, Avenida la Libertad or Avenida Libertad, using spell menu
is much faster. Would it be possible to get partial searches working in
address search?
I know that this is technical possible and expect it to work in the near
future.
Actually, we do have a mean: if there are multiple parallel tracks (each
drawn as a separate way with railway=*), it is a major railway. It
should be doable to merge adjacent ways at lower resolutions and sum the
weights of the ways, to decide what to draw. A style file extension
could be
Am 19.03.2011 13:36, schrieb Steve Ratcliffe:
Should we print out a warning if someone still uses the options charset
and/or lower-case? Or should we remove these options?
This seems to be a common pitfall since the index branch has been
merged.
I agree, and go further, I would like to
Why did you change the merge-lines text at the same time?
--merge-lines
Try to merge lines. This helps the simplify filter to straighten out
longer chunks at lower zoom levels. Decreases file size more.
Increases paint speed at low zoom levels.
*At the moment this option
Hello,
Would it be possible that the new street search will be directly
supported by mkgmap without uploading the map using Mapsource to the
GPS device (nüvi)?
At the moment it is not yet implemented. Priority task now is to get the
index running without errors. If this is finished, then the
Am 09.03.2011 16:10, schrieb Rich:
On 03/09/11 17:00, Marko Mäkelä wrote:
On Wed, Mar 09, 2011 at 04:02:38PM +0200, Rich wrote:
so it might be that the file has properly encoded characters, but the
device does not properly display them ?
That is a possibility. Do the older Garmins (such as
Am 03.03.2011 22:56, schrieb Felix Hartmann:
On 03.03.2011 22:37, Felix Hartmann wrote:
For lines it works perfect. But somehow polygons really get munged and
destructed (lots of straight line holes - that are fewer without this
patch).
Could you check what is going on for polygons? For
Am 03.03.2011 13:35, schrieb Markus_g:
I Hope there is a way to turn it off. I like forests and national parks, etc
coming in at zoom 16 so I can get the big picture on what's around. I think
it should be the style file that sets when things should be displayed.
At the moment there is no
Am 03.03.2011 20:11, schrieb Johann Gail:
Am 03.03.2011 13:35, schrieb Markus_g:
I Hope there is a way to turn it off. I like forests and national
parks, etc
coming in at zoom 16 so I can get the big picture on what's around. I
think
it should be the style file that sets when things should
Okay I've done some comparisons between the two approximations.
For polygons the old version is much better because the patched version
creates bad artifacts. For streets at resolution 23 (if used) to 21 I
prefer it too. At resolution 20 I am indifferent and cannot really
decide what is
Am 03.03.2011 21:54, schrieb Johann Gail:
Okay I've done some comparisons between the two approximations.
For polygons the old version is much better because the patched
version
creates bad artifacts. For streets at resolution 23 (if used) to 21 I
prefer it too. At resolution 20 I am
Am 02.03.2011 14:03, schrieb Felix Hartmann:
On 02.03.2011 13:53, Marko Mäkelä wrote:
On Wed, Mar 02, 2011 at 01:45:52PM +0100, Minko wrote:
Negative consequence is that on Mapsource most of the forest disappears
too soon, when zooming out.
How hard would it be to merge nearby polygons on
Okay I've done some comparisons between the two approximations.
For polygons the old version is much better because the patched version
creates bad artifacts. For streets at resolution 23 (if used) to 21 I
prefer it too. At resolution 20 I am indifferent and cannot really
decide what is
while i'm here, i also tried lowercase option - it mostly worked except
for labels on roads where all lowercase symbols seemed to be replaced by
underscores. is that something that can be improved with mkgmap, or is
it a quirk of the garmin device ?
Most Garmin units cannot display rotated
1-The list of regions (state/country field) is much better than the one
obtained with trunk. All those included are actual regions (some with
two different names, e.g. Castilla la Mancha Castilla-la Mancha).
Trunk includes many names that are not actual regions of Spain, but
provinces,
There is a section MDR8 which I added which is an index of
the first four letters of the street name into the streets section.
Now I think that would probably work OK, but there is one problem.
In one case there is Calle spelt with a C-cedilla Çalle (is that
even correct?).
Anyway when I
Hi Valentjin,
IIRC then there are some limitiations in the format, which don't allow
more than 256 tiles in one img file.
There should be no exception but a clear error message, but I think it
would not work anyway.
Regards,
Johann
Valentijn Sessink schrieb:
Hi list,
This should have been
(2) Missing all streets beginning by Calle before Calle Real ...
I suspect (like Johann) that having so many streets beginning with the
same letters is confusing. But surely it is confusing to humans too? How
are Spanish street directories normally indexed, do you normally ignore
Carlos Dávila schrieb:
These are my results with index_branch r1792
1 tile map
2 tiles map
9 tiles map
*POI search*
Yes
Yes
Yes
*Cities*
Accented characters
Yes
Yes Yes
Existing city
Yes (3)
Yes (3)
Yes (3)
Existing region
Just a thought while reading this:
Has the MDR1 to be sorted in some way? Maybe the mapnames has to be
sorted in ascending order?
I think mostly they are sorted by pure random in ascending order because
splitter creates an argument file this way. This would explain the crash
with other
Steve Ratcliffe schrieb:
Hi
I had some looks at the code, especially on MDRSection7, which is
important for street search. And, yes, there are some more fields
decoded. But most of the comments are in polish, so it's very hard (at
least for me) to unterstand what those fields are used
WanMil schrieb:
Has anyone dared to look into the cpreview code?
So we do at the moment.
http://cgpsmapper.svn.sourceforge.net/viewvc/cgpsmapper/cgpsmapper/cpreview/mdr_creator.cpp?revision=4view=markup
There seems the structure of the bits be very well decoded.
More or
I started to strip down the index branch to things that work so that we
can add more and more things until we get a running index branch.
As a first step I modified the OSM reader so that there will be no
special character for sure. All non recognized characters
('a'-'z','A'-'Z','0'-'9','
WanMil schrieb:
Am 19.01.2011 20:15, schrieb WanMil:
I started to strip down the index branch to things that work so that we
can add more and more things until we get a running index branch.
As a first step I modified the OSM reader so that there will be no
special character for sure.
WanMil schrieb:
Hi
I observed the same result when I added the MDR8.
Adding MDR12 returns to the old behaviour with exceptions and MapSource
crashes.
Thanks that was a good clue I hope. I modify the size of the section
mdr11 in the routine that writes it out. As all the
In mdr_creator.cpp in line 1291 is a difference between mdr8 and mdr12.
The lenght of the mdr12 dataset needs place for one more bit. I cannot
I will double check, although I probably deal with it.
find any code where the mdr12 gets written out, so I cannot see the
meaning of the
9 tiles
Almost the same results than 1 tile. The first difference found is that
there are a lot of missing streets.
Is there a pattern with the missing streets? Maybe only the streets from
tile 1 are found, but not from the higher?
___
mkgmap-dev
Has anyone dared to look into the cpreview code?
http://cgpsmapper.svn.sourceforge.net/viewvc/cgpsmapper/cgpsmapper/cpreview/mdr_creator.cpp?revision=4view=markup
There seems the structure of the bits be very well decoded.
___
mkgmap-dev mailing list
I use it for test maps that I generate from JOSM files. In such files
there are tons of osmbounds and IIRC mkgmap only uses one of them
(first, last?) and the rest of the data gets thrown out. In that case I
use ignore-osm-bound to ensure all data is used in the map.
Indeed I realise
In the end as cpreview that generates a fully working address
search for cgpsmapper produced maps is open source now, it should be
possible to get mkgmap write correct address search too. I have not
succeeded in using cpreview to write working mdr for mkgmap created maps
though.
I
Hi,
since many month I'm using splitter for maps creation. Since this time,
I use the same PC, so the hardware has not changed.
I always was able to splitt the europe osm map. The splitting needed
some minutes. I didn't check it, perhaps it were 15min, but in no case
longer than 15min.
It would be great if we have a tool that reads the IMG-file and creates
a statistic of how many objects are contained in the file. Do we have
that already?! I think I remember a thread about that but I cannot find
it.
IIRC, there is something in the mkgmap svn repository,
On 11.12.2010 18:10, Clinton Gladstone wrote:
It looks like the author has only published two parts of cgpsmapper so far:
cpreview - tool for index generation and preview files generation
mapRead - sub part of cpreview - allowing fast access to IMG file
That's interesting enough in
If you use the option reduce-point-density then the line is straightened
using the douglas peucker algorithm. All segments between two endpoints
or T-crossings are straightened. The points of crossings are not
touched. Find a description of the algorithm at wikipedia.
I don't have enough insight to the file format but this could well be
the case.
Could you explain in a few words, how it works?
The NOD section is like you describe it.
The point about the different levels being linked is in the NET
section. Here is a a single road in NET:
Hello Steve,
I'm the origin writer of the mergeline code. It was a try to improve the
effectiveness of the dp filter. When a nearly straight way consists of
severeal short pieces, dp filter could not do much. If the segments are
combined beforehand, dp filter could work much better and combine
Currently the --merge-lines works in all resolutions. However in
resolution 24 and 22 there is not much speed improvement on the GPS, but
it's quite annoying that the information pop up on hoover shows in the
wrong place.
I can vaguely remember seeing a similar effect a year ago. I
Just for reference. I found the old thread:
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg03680.html
Thanks for searching the old thread. It is true, now I can remember too.
The problem was (and I think is) that the routing tables are generated
before the merging. So the
Let's hope that Stan as promised open sources cgpsmapper by the end of
this year
Thats interesting news to me.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Would you happen to have an idea how to tag (and in mkgmap) hide a
highway=service tunnel for accessing a railway tunnel?
This is very much a special case. It is the result of several factors
working together. One of the factors is that Garmin devices do not give
a clear indication of
Johann,
the idea to printout a warning sounds good. But there are some
restrictions within mkgmap that makes it unfeasable.
Yes, unfortunatelly I know the internas somewhat :-)
When mkgmap reads the OSM data all tags which keys are not referenced in
the style files are dropped. This
What I believe could be useful (if this feature is already
available then forgive me posting) would be an option to
report ignored tags and tag/value pairs which would alert
the user that certain features are not rendered by the
current style.
I don't think this is doable. There are
Follow street or beeline
No ideas where this message comes from?
I don't want you to think that your question is being ignored, but I
have no idea what that message is -- the only reference to that phrase
on google is now your own question!
I do not know, what causes
or
is it expected not to work?
Regards,
Johann Gail
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I can confirm this: after transferring maps to my eTrex with either Mapsource
on Windows/Wine or MapInstall on the Mac, address search works -- at least
with the known limitations of mkgmap's index generation.
I have not recently attempted to copy a generated gmapsupp.img file to my
As far as I understand, the mkgmap --index option produces half-cooked
files that must be transferred by MapSource to the device. Once that is
done, the search should work. Others can hopefully chime in; I have
never used MapSource.
Same situation for me. I have never tried, but am
I have used *.bin as an extension, but I am open to suggestions.
I find *.bin a little general. Most of files are bin. I would suggest
instead *.osm.bin
A abbreviation of the phrase 'protobuf binary format' would give *.pbf.
Both from 'ProtoBuF' and from 'Protobuf Bin Format'. The more
Is there an easy way to extract the sub-files of a Gramin img file, either
by using some of the mkgmap code or another piece of software? I am
interested in delving deeper into the file format and playing around with
the unknown areas.
You should have a look at the tools mdrdisplay,
I use to map specialy hiking trails. I do not know if it's possible to
use routing thru trails and paths across mountains.
Francois
In general it should be possible to route about trails and paths. For
this you have to define the correct access rights for this ways in the
types file.
I believe that you need to recompile mkgmap from scratch, do 'ant rebuild'.
I did that, to no effect. Though in the spirit of your suggestion, I
could blow away my code and check out from scratch, if you think that
might help.
Dermot
Yes, that might help. The error
Hello,
I would like to know if it's possible to run the splitter against two or
more files on the same run? For example, is is possible to run splitter
that way :
java -Xmx896m -jar splitter.jar --cache=~/tmp
--geonames-file=cities1000.zip --max-areas=30 --max-nodes=100
You can split mutliple files in the same run no problem (using the same
syntax
as in your example), [...] In fact it's quite likely that at least one tile
(probably
more) will contain nodes from BOTH osm files, [...]
Be carefull with this maps. It is a known issue, that routing over
Right, the default style has to work for all routing. We cannot tweak it
to improve bicycle routing, if the tweaks would ruin car routing.
[...]
What if we had a separate style for bicycle routing, with road_class and
road_speed defined in such a way that minor roads are preferred?
I dont know the internal of the multipolygon code, but this number is in hex
4000121B
So I think the upper bit is used for somthing. If I mask it out I will
get 121B and this will be 4635 in decimal. Could this be the faulty
relation?
Regards,
Johann
Dermot McNally schrieb:
Hi folks,
PARVEEN ARORA schrieb:
Hello Every one,
I am Parveen Arora .An engineering student.
I am doing a project of setting osm -server for Our state punjab in India
and to develop its and features of Main OpenStreetMap.
i have followed the instruction given at the following website.
A possible way to find the flag:
With MapSource (at least with 6.13) it is possible to include or exclude
the routing data when transferring to the device. If you transfer the
same data twice, one time with, the ther time without the routing data,
A great idea!
Unfortunately my
The first bit in poiDisplayFlags have to do something with the basemaps.
In all detailed maps it's set.
The maps i found that it's not set are worldwide base maps - gmapbmap.img(s)
For the route recalculation, it's not clear which of the two bites
changed the recalculation
- first rule of re
I've now got a small example that shows the problem.
No luck so far in finding the flag, if indeed it is just a flag.
A possible way to find the flag:
With MapSource (at least with 6.13) it is possible to include or exclude
the routing data when transferring to the device. If you
Only solution I think is to make --route default and
compulsory for the moment. Else people will create maps that havoc other
maps without realising.
I strongly advice against this. The problem has been around a very long time
and nobody noticed, so I don't think it is that
Felix Hartmann schrieb:
On 27.05.2010 13:12, Johann Gail wrote:
Setting the fourth via gmaptool breaks the routing for routable maps
even though it should be there for setting maps tranparent/opaque is
some obscure way different from the general transparent/opaque flag
Could
This is the point which confuses me at the moment. This bit does
influence routing in some way. But you say that there are nonroutable
maps with this bit set/unset. So what could the meaning of this bit be?
Noone really knows. Mkgmap sets it even. Garmin maps are actually
allways
The transliteration is for sure done in mkgmap and not in the garmin
unit. But don't ask me details, where and how it happens.
Claudius Henrichs schrieb:
Currently if the name-tag is written in persian or arabic script on a garmin
device it ends up transliterated into latin script. I am not
I think Roman numbers should be displayed as upper case roman number, at
least when they are part of a ref or name. If you have always seen a
street name as, say Juan XXIII it may be difficult to recognize it as
Juan 23. For dates it could be better to translate into Arabic numbers
as
I'm entirely in favour of removing 'fix my address', but Thilo (who
wrote the patch) said that it shouldn't be committed.
See: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q2/008177.html
I don't know the patch, but I am in the same opinion, to remove the 'fix
my adress'. Why not
Johann Gail wrote:
Its IMHO not a good solution, but very flexible to introduce new options.
I asked since it seems a bit magic to me where the options are
processed. If I for example search over the src directory with Windows
search for all files that contain areas in, I
ok, that was a bad point to start with. but another question: where is
the entry point where the options are processed?
TIA, Dani
There is no central entry point for option processing. It is scattered
over the whole application. There is a central class CommandArgs.class,
but there
Felix Hartmann schrieb:
It would be better to have more aggressive dp-filter instead. As I
wrote a while back, the increase of the dp filter in low resolutions
has to be much higher. Currently a level of 10 is very good, but too
strong for resolutions 23-21 and a bit too strong for 20.
motor_vehicle is not understood by mkgmap
Actually, why not? If my memory serves right, mkgmap understands
motorcar and motorcycle (and maps them to the same access bit), but why
not motor_vehicle? For example in my understanding, tractors are
covered by motor_vehicle but
motor_vehicle is not understood by mkgmap
Actually, why not? If my memory serves right, mkgmap understands
motorcar and motorcycle (and maps them to the same access bit), but
why not motor_vehicle? For example in my understanding, tractors
are covered by motor_vehicle but not motorcar
Turn restrictions are implemented like this
[Restrict]
Nod=29298
TraffPoints=29431,29298,29431
TraffRoads=4791,4791
Time=
[END-Restrict]
What I find interesting in this excerpt:
It has a definition for time. I expect here the validity times for this
restrictions. This would mean,
Hello Johann,
It has a definition for time. I expect here the validity times for this
restrictions. This would mean, that the garmin img format can handle this.
Sure it can - Garmin turn restrictions can be a lot more complicated
than we know how to encode.
If you want to
Have you tried compile a map with the default style files?
Regards,
Johann
Marco Certelli schrieb:
Hello, Mark is trying to reproduce the error I got on my PC but He couldn't
so far. I'm now trying to rebuild img on another PC. I'll let you know about
my new tests as soon as I have news.
Thank you for the detailed explanation.
1) Nodes and ways get intermingled in the output OSM file. I don't think
this is a problem at all since there still won't be any forward references
from eg ways to nodes, but currently the splitter writes out node/ tags
first, then way/ tags, then
2nd: Ways should be included if they intersect the bounding box.
For me it would be perfect if ways are included with all nodes. But it
is also ok if all inner nodes and for all parts of the way the first
node out of the bounding box is included. This enables me (and others)
to calculate
I've investigated doing this in the past however it's very tricky to do
correctly
without having a huge impact on performance and/or memory requirements. I
do have one idea that might work without too much slowdown. If I was to build
up a big disk index of all nodes (there is already a
1) determine where the tile boundaries lie, based on the distribution of
nodes in the osm file. None of these tiles will overlap.
2) for each node, determine which tile (or tiles) it belongs to. A node is
considered to belong to a tile if it falls anywhere within the tile itself
OR the
But I see a technical problem arise:
In the filter chain there aren't any more tags or other information on
how polygons are connected. There are only the raw polygon objects with
coordinate data.
Do you mean the multipolygon information which polygons belong to the
mulitpolygon
Ralf Kleineisel schrieb:
On 01/09/2010 10:08 AM, WanMil wrote:
Another idea is to add some specific tags by the mulitpolygon algorithm
that link to the other pieces of the formerly big forrest. This could be
evaluated by the SizeFilter?
Another idea (don't know if this is
Another idea (don't know if this is possible):
You have a big multipolygon forest. You could duplicate it. One copy
without small inner polygons for the low resolutions. Another copy with
the inner polygons which gets splitted for the higher resolutions. The
copies could be marked with some
Felix Hartmann schrieb:
That patch works pretty nice. I upped the value to 40 and that gave
nice results when zoomed far out.
Here is the settings that I would find optimal
resolution 24 == 4 (I think 4 is anyhow the minimum because if less
than 4 pixels than it ain't an area)
resolution
That patch works pretty nice. I upped the value to 40 and that gave
nice results when zoomed far out.
Here is the settings that I would find optimal
resolution 24 == 4 (I think 4 is anyhow the minimum because if less
than 4 pixels than it ain't an area)
resolution 23 == 6 ( resolution 23
Essentially the best option for drawing Polygons would be to determine
their resolution based on size. So make large forests appearing at
lower resolutions than small forests (well I think we all know that best
would be if resolution of any element were adapted to map density, but I
The proper solution would be to merge polygons if they overlap at the
current resolution. Otherwise we might get holes in forests if they are
mapped in small pieces. But I have no idea how to implement that...
Which would be rather counterproductive to the PolygonSplitter code :-(
The
Thilo Hannemann schrieb:
Am 07.01.2010 um 23:22 schrieb Johann Gail:
The proper solution would be to merge polygons if they overlap at the
current resolution. Otherwise we might get holes in forests if they are
mapped in small pieces. But I have no idea how to implement
At the moment there is a commandline switch
(-reduce-point-density=xxx) which allows you to set the dp error
distance for each call. It should be doable with nearly no effort to
introduce a second option for polygon settings.
Just added a patch with an additional option
Maybe the splitting should be done *after* the dp step.
Have just looked into the code.
The splitting with PolygonSplitter *is done* after the dp step. So this
is ok.
But while looking at it I found a severe error in the splitter code.
See attached picture.
If the polygon gets split at 6,
It's a great shame that we can't enable assertions by default.
Just looked at the java docs and found the following:
Programmers of certain critical systems might wish to ensure that
assertions are not disabled in the field. The following static
initialization idiom prevents a class
Could someone please commit or deny the patch. It is open for a long
time, no one has complained about it and I think it's a useful
enhancement.
Sorry, I don't see the use of a black/whitelist of tags.
The information of used tags should be contained in the style files, so
why
I'm having an issue with routing in southern Minnesota along I-35 with
my Oregon 300 (firmware 3.40). If I pick two points along I-35, one
south of Albert Lea and the other north of Owatonna my Garmin wants to
route me over to US 218 instead of using I-35. The same route using
Cloudmade
Any way can now be flagged as a carpool lane by giving it a
carpool tag (e.g. carpool=yes).
Shouldn't the tag be named 'mkgmap:carpool', accordingly to the other
newly inroduced tags?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Mark,
congratulations to your success with the unpaved bit.
For the keyword I would use mkgamp:unpaved, as some others has suggested
too. In my opinion most if not all tags used by mkgmap should start with
this prefix and should be translated in the style file.
Regards,
Johann
Mark Burton
I think it should be possible without too much effort.
At least the internal class GType has the fields Minresolution and
Maxresolution already implemented. From my sight it should be a small
change in the TypeReader parser.
___
mkgmap-dev mailing list
Hi Tino,
For reference: I've already posted about this in the thread [PATCH v1] Merge
similar lines and ways.
You'll have to do the merging after the processing of the ways, but before
the IMG file is created. As the current code creates the IMG file on the
fly during processing, there is
My guess is...
After merging you have 1 graphical line that spans the length of the
combined lines associated with a routing arc that only spans the length
of the original un-merged line. When you put the cursor near the lines
that have been merged, mapsource, finds the arc associated with
Okay, the merge-lines seems to be responsible for it! - However also
very aggressive dp filter settings might cause the tooltip to show up
slighltly away from the mouse (the tooltip will show up where the road
would be in resolution 24) - however only when using --merge-lines the
tooltip
1 - 100 of 146 matches
Mail list logo
