Hi Marco,
the relationship between the maxspeed tag and the road_speed is
hardcoded in mkgmap. This is reasonable in general, because otherwise
the style files had to be much larger to cover all the possible
road_speeds per road. But if you want to use the road_speed in a
creative way
Hi Mark,
It occurs to me that some people will want the maxspeed tag to
override
the speed code in the rules file (obviously, the person who wrote that
code thought it was a good idea) but others, like Marco, would prefer
not to have that feature. So, I guess, we need (yet another) option to
Hi Mark,
I tried to do so, but the small file was processed without error :(.
The big one is available at a website though (http://osm.arndnet.de/problem.osm.zip
). The problem to reproduce that error is that it occurs for me only
if I merge contourlines that I generated on my own (not with
Hi Felix,
Am 03.06.2009 um 12:06 schrieb Felix Hartmann:
Is it possible to encode arbitrary maxspeed values or can we only
set in steps of 10km/h?
For example having road road_speed=7 associated with 35km/h, road
road_speed=6 with 27, road_speed=5 with 23, road_speed=4 with 20,
The attached patch allows to generate ways from a relation. To do so
simply write the way generating statement into your relations style
file, e.g.
type=route route=bicycle network=tcn { name 'Touristic
cycleroute' } [ 0x02 road_class=3 road_speed=6 level 3 ]
Hi Elrond,
there seem to be some problems with the simplification right now. But
instead of simply de-activating the simplification I think we should
debug the code. Of course it's fine to de-activate it for debugging :)
The problem of distorted polygons does not only appear in the
Hi Mark,
Am 16.06.2009 um 08:33 schrieb Mark Burton:
Recently, Coord.distance() was replaced with a much speedier
implementation because a lot of cpu cycles were being wasted there.
The newer function appears to be accurate enough for our purposes.
The DP code contains another distance
Hi Mark,
Am 16.06.2009 um 09:18 schrieb Mark Burton:
At the distances we're (mostly) interested in, the curvature of the
earth's surface has a tiny effect (much less than the effect of
hills
valleys) so I guess (hope) that leaving out that factor is OK.
The curvature may have a tiny
Hi,
Am 16.06.2009 um 20:39 schrieb Elrond:
My current conclusions from both thread parts:
1) I should only disable the SizeFilter (we really, really
don't want to drop any polygon).
For the overview map obviously not.
2) We should fix DP.
From what you explained about the overview map
Am 16.06.2009 um 18:33 schrieb Marco Certelli:
Just speculation:
I've a and b that defines a line. I look for the distance between a
point p and the line.
Given the triangle p-a-b where p is the vertex and a-b is the
base, the area of the triangle can be calculated from the lenght
of
Here is another approach to the lost last point. The Douglas Peucker
filter is improved so that it can deal with identical start- and
endpoints. If the start- and the endpoint are identical, the algorithm
calculates the distance between these identical points and the point
p. So the
Hi Marko,
I've started to compile a list of the behaviour of different GPS units
with regard to POIs. As the different units handle the POIs
differently it is important to have such a list, because what displays
on your GPS unit just fine might be invisible on a different unit. For
now I
Has anybody had success controlling the drawing order with the --
preserve-element-order option?
The drawing order is random for me, with or without this option. Would
be nice to get it working, though, especially for overlays.
Regards
Thilo
___
Hi Christian,
Am 30.06.2009 um 23:33 schrieb Christian Gawron:
I already wrote a class to read SRTM data directly with mkgmap, i.e.
without having to create the contours as separate (huge) files.
This is very much encouraged. For the contour lines the computing
times may be that long that
Hi Felix,
you say that the draw order of the polylines depends on 1. type and 2.
id. What do you mean by id? Is that the OSM id? Or do you refer to the
order the lines are written into the .IMG file?
From what I see it certainly depends on the type of the polyline, but
in a way that I do
I've attached Toby's patch. I'm using it and it works well, *if* the
polyline is long enough. When using it for cycleroutes for example
they tend to be made of lots of tiny pieces and the road symbols won't
be displayed.
highwaysymbols.patch
Description: Binary data
Another patch you
This one is a little complicated:
When using the --add-pois-to-areas option, for every shape whose tags
will match an entry in the points style file, a POI entry in the map
will be created in the center of the shape (if there is not already
one POI with the same name inside the shape). The
Hi Christian,
congratulations, that is very good work.
As there are some people on this list who will publish their created
maps I'll have to add a caveat though: You should make sure that the
data source you use for the generation of the contour lines is
compatible with the OSM license.
24.07.2009 um 23:11 schrieb Johann Gail:
Thilo Hannemann schrieb:
Here is another approach to the lost last point. The Douglas
Peucker
filter is improved so that it can deal with identical start- and
endpoints. If the start- and the endpoint are identical, the
algorithm
calculates
Hi Johann,
Am 25.07.2009 um 10:54 schrieb Johann Gail:
A further development would be, to consider only nodes which are
visible
crossings at the current zoom level. I.e. if a residential connects
to a
big road and the residential is not visible at the current zoom level,
then it is
Hi Felix,
Am 25.07.2009 um 13:05 schrieb Felix Hartmann:
Yeah, merging roads if possible would be great. Even more important
would however be smoothing of curves. i.e. make serpentine corners on
mountain streets more smooth, because otherwise if there is a say 160°
corner, it will add a big
There is an application called Java-Einstellungen (probably Java-
Setup in English) that is part of MacOS 10.5 (or the Xcode tools,
don't know). I just changed the setting there and everything worked
fine. No need to fiddle with frameworks and environment variables.
Regards
Thilo
Am
Hi Mark,
Am 06.08.2009 um 21:49 schrieb Mark Burton:
The way I see it is:
1 - the mkgmap style engine is good for moderately complex styling.
2 - for more demanding styling, either the mkgmap style engine has to
be fixed/enhanced to support whatever new demands people want to make
on it,
Hi Mark,
Am 06.08.2009 um 23:52 schrieb Mark Burton:
I disagree.
The patch simply provides a means for those people who have complex
styling requirements to roll their own styling engine so they are
not
obliged to use whatever is built into mkgmap. The presence of the
patch
will not
I'm currently working on it. Have you tried the patch together with
routing? In my trials the routing was completely broken after applying
the patch. That is because the merging is done *after* all the routing
info is generated. So if two ways are merged into one, the references
in the
Hi Mark,
Am 15.08.2009 um 13:45 schrieb Mark Burton:
However, looking at the code it seems to me that the merging happens
after StyledConverter.addRoad() is called and that is where the way
lengths are limited. So you either have to do the merging earlier, or
you need to add a constraint to
Am 16.08.2009 um 23:14 schrieb Nop:
Thilo Hannemann schrieb:
One feature, one OSM-object
Don't place nodes in (equally labelled) areas just to see some icon
appear on the map. The renderers will display icons on areas as well
and there's no need to have every parking-lot, soccer-ground etc
Am 19.08.2009 um 22:01 schrieb char...@cferrero.net:
I've created a partial list for the GPSMap76Csx though my aim was
slightly different (I wanted to understand what symbols the hex codes
translated into). Is there any way we can fork this page into
separate pages per unit otherwise it will
Am 19.08.2009 um 22:17 schrieb Simon Josefsson:
How do I use the test-map:all-elements feature?
(I have a problem with highway=service roads on my Legend HCx when it
uses Swedish, it labels the roads as Allé which I suspect is a
mis-translation of Alley -- solving this might require firmware
Am 21.08.2009 um 12:43 schrieb Felix Hartmann:
Is noone else using these features? Thilo, what about you? Are you
able to use 1140 as a base?
Hi Felix,
sorry, I didn't see that thread earlier. The feature with the
relations that you are using was never integrated into trunk. I assume
Hi Mark,
for collecting OSM tracks with your Nüvi you will want one where you
can switch off the show on road behaviour. If you can't switch that
off your tracks will always be exactly on top of the roads that are
already in the map. Very much useless for OSM mapping.
With my Nüvi 255W I
Hi Ben,
perhaps it is not really obvious from the documentation, but you can use
regular expressions. The syntax would be
name ~ 'T.*'
for example. Note the .* instead of a single *, this is a proper regexp and
not the simplified version. For reference I would suggest something like
One idea for rounding at that level:
Most annoying is that rectangles that are buildings aren't rectangles anymore
after rounding. As the OSM data in itself probably isn't accurate at the 2 m
level perhaps we could do tweak the coordinates so that rectangles stay
rectangles (I know, the
The Douglas Peucker Algorithm might not be the best way to tackle the problem
of too small polygons. Right now polygons will be dropped if they have a
maximum extension of less than one map unit at the current resolution. The code
is in mkgmap/filters/SizeFilter.java if you want to try it, just
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 that...
Which would be rather
in the roads
at all and can set MIN_SIZE to a bigger value for the polygons.
Regards
Thilo
Am 08.01.2010 um 15:52 schrieb Felix Hartmann:
On 07.01.2010 23:13, Thilo Hannemann wrote:
The Douglas Peucker Algorithm might not be the best way to tackle the
problem of too small polygons. Right now
I've tried the patch as well and it works nicely. Smaller maps, some map
clutter removed and seems to be faster as well.
Regards
Thilo
Am 08.01.2010 um 21:48 schrieb Johann Gail:
Felix Hartmann schrieb:
That patch works pretty nice. I upped the value to 40 and that gave
nice results
AFAIK the POI searches work only with the actual POIs that are generated, not
the polygons. So this should be no big problem. You should make sure though
that the --add-pois-to-areas option doesn't generate the POIs twice.
Regards
Thilo
Am 09.01.2010 um 11:56 schrieb WanMil:
Am 09.01.2010
I'd also think that the multi-layered approach would add a whole new level of
complexity to mkgmap. And it is a feature that no official Garmin map has ever
used AFAIK. You even get different results depending on your MapSource
*version*. So I don't think it is a something that should be built
The reason why you need a matching polygon rule for POIs to be generated is
that mkgmap needs this to find out that it is a polygon.
Why is this? Because there is no way to find out whether a closed line is
actually a polygon or a line/way besides looking at the tags. From the OSM
standpoint a
Am 29.01.2010 um 17:47 schrieb Christoph Wagner:
Thilo Hannemann schrieb:
The reason why you need a matching polygon rule for POIs to be generated is
that mkgmap needs this to find out that it is a polygon.
Now I really understand the problem. Would it be enough for mkgmap to specify
Hi Adrian,
Am 30.01.2010 um 23:40 schrieb Adrian:
Another Garmin foible... Sightly off-topic, but I thought this was the
best place to post this information.
I have a Streetpilot c550 and an etrex Legend HCx. On both, the last
zoom setting at which railways are visible is 800ft (resolution
Attached is a patch that allows you to build routable ways from relations.
generate_ways_from_relations.patch
Description: Binary data
You use it by adding a [ ... ] section in your relations style file. For
example:
type=route route=bicycle network=tcn
{
name
Hi Christoph,
you'll find the answer here:
http://nsis.sourceforge.net/I_get_an_error_when_compiling_large_installers
There seems to be a limit in the archive format of the installer so that the
compressed data may not be larger than 2 GB. The recommendation is to use a
multi-volume install
Am 08.04.2010 um 12:48 schrieb Christoph Wagner:
I am not a windows hacker and have no knowledge about the nsis system.
Maybe we could add some params to the --nsis option of mkgmap like:
--nsis=nodata
or something to avoid including the files in the exe directly.
In principle you could
The attached patch will prevent writing the additional POI information
(address, phone number) if
- it won't be shown (POIs with IDs 0x64xx to 0x66xx won't have their
information shown)
- there is no street given for that POI
reduce_unnecessary_poi_infos.patch
Description: Binary data
This
Am 18.04.2010 um 19:15 schrieb Felix Hartmann:
On 18.04.2010 10:46, Thilo Hannemann wrote:
I'm not sure about the ID range 0x64xx to 0x66xx - has anybody tested this
and knows whether there are additional IDs that won't have their information
shown?
Regards
Thilo
Actually it is much
When looking at the code I'm not so sure anymore that this patch does what I
expect it to do. So please do *not* include it into trunk. I'll think about it
and will come up with another one.
Regards
Thilo
___
mkgmap-dev mailing list
Am 19.04.2010 um 22:32 schrieb Charlie Ferrero:
My tests suggest that only POIs in the range 0x2A00 to 0x32FF can carry
address information.
Hi Charlie,
could you elaborate on that? What tests did you do and with what kind of
GPS/software? My experience with the Garmin stuff is that this
Some stats about the patch:
With my map (OSM Radkarte) the difference in size of the gmapsupp.img is
626622464 bytes (with patch) to 638369792 bytes (w/o patch), that is a
reduction in size of about 1.8 %.
Regards
Thilo
___
mkgmap-dev mailing list
In the code handling the mkgmap:gtype tag the road class is set twice, but it
should be the road speed the second time. See the attached patch to correct
this.
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
---
51 matches
Mail list logo
