Dave F. wrote:
> Hi
>
> When using this command line:
>
> java -Xmx512M -ea -jar mkgmap.jar --transparent
> --style-file="c:\dwgs\Programs\GPS All\Garmin Profile" --family-id=42
> M02.TYP 63272002.gz
>
> it creates a 63272002.img using my customized styles & when uploaded
> appears as I w
Hi
When using this command line:
java -Xmx512M -ea -jar mkgmap.jar --transparent
--style-file="c:\dwgs\Programs\GPS All\Garmin Profile" --family-id=42
M02.TYP 63272002.gz
it creates a 63272002.img using my customized styles & when uploaded
appears as I would expect.
But when I use the sa
On 14.02.2010 23:53, Ronny Klier wrote:
Hi,
there seems to be a way to show elevation profiles for a route without
having the DEM subfiles stored in the map.
There is a byte in TDB file's header section which can be set to 1. If
set MapSource generates the profile from the contour lines. The
Hello Torsten,
> Mark Burton schrieb am 14.02.2010 20:05:
> > Yes, as the Garmin map resolution is approx 2.2m, it is understandable
> > for your road to have those dents.
>
> But the offset of the points look much bigger than 2.2m. And this doesn't
> explain, why the north-south ordering of the
Hi WanMil,
> Compared to v3 (posted by Carlos in thread "Wrong multipolygon
> warnings") some unused debug messages have been removed.
>
> The patch enables the multipolygon code to process multipolygons with
> overlapping lines.
For the Geofabrik Finland extract of today, the patch reduces th
On 14.02.2010 20:53, Torsten Leistikow wrote:
> Mark Burton schrieb am 14.02.2010 20:05:
>
>> Yes, as the Garmin map resolution is approx 2.2m, it is understandable
>> for your road to have those dents.
>>
> But the offset of the points look much bigger than 2.2m. And this doesn't
> exp
Mark Burton schrieb am 14.02.2010 20:05:
> Yes, as the Garmin map resolution is approx 2.2m, it is understandable
> for your road to have those dents.
But the offset of the points look much bigger than 2.2m. And this doesn't
explain, why the north-south ordering of the two points is in JOSM invers
Hello Torsten,
> 2. In the attached screen shot you can see the resulting map created by the
> attached OSM-file. If you zoom in very closely, there is a dent in the
> secondary
> road. If I open the OSM-file in JOSM, there is no such dent visible. Is this a
> data resolution problem of the Garm
Hi Clinton,
> On Feb 14, 2010, at 11:32, Minko wrote:
>
> > set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' |
> '${name}';
>
> Just out of interest, should the parentheses surrounding
> mkgmap:boundary2_name not be curly brackets ('{', '}')? I noticed this
> in the default style as
Am 14.02.2010 01:11, schrieb Carlos Dávila:
> WanMil escribió:
>> Am 13.02.2010 17:56, schrieb Carlos Dávila:
>>> WanMil escribió:
I have attached a patch for revision 1568. Hopefully this will
work...?!?
WanMil
>>> I reply off list because of the size of the attachments.
>
Compared to v3 (posted by Carlos in thread "Wrong multipolygon
warnings") some unused debug messages have been removed.
The patch enables the multipolygon code to process multipolygons with
overlapping lines.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
Garvan & maew wrote:
> You could try converting the file with gpsbabel
>
> gpsbabel -i kml -f test.kml -o osm -F test.osm
>
> And then see if you are happy with the translation, or if you still need
> to add more features. At least you will have a starting point on what
> tags you need.
Thanks fo
v3 - bug fixes:
now ignores through_route relations if the junction is outside of the
tile's bounding box
should no longer think that ways that have been split do not start
or end at the junction.
v2 - no longer requires the node to have role "junction"
This patch als
Yes, now you metion it, I notice that too.
If I change the ( . ) for { . } which seems more logical, it will give
not the display at the borders that I want.
At the National Border between Netherlands and Belgium for instance, now only
Belgium is displayed instead of the desired two nam
On Feb 14, 2010, at 11:32, Minko wrote:
> set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' | '${name}';
Just out of interest, should the parentheses surrounding mkgmap:boundary2_name
not be curly brackets ('{', '}')? I noticed this in the default style as well.
Or is this a syntax w
>> Hi
>>
>> I'm trying to convert a .kml (google earth) to .osm so I can use mkgmap to
>> convert to .img.
>>
>> In the .osm file I've noticed that mkgmap appears to ignore the
>> tag.
>>
>> To simplify my conversion, are there any others that aren't utilized?
>>
>> For instance, in the node d
Hi all,
It looks like I managed a way to render those complex multipolygon
administrative borders correctly now.
In the relation style file, I changed administrative borders statements like
this:
# country borders
(type=boundary | type=multipolygon) & boundary=administrative & admin_level=2
{
17 matches
Mail list logo
