have done for srtm data for parts of US and viewfinder data in the alps
started today to automate it for US based on NED 1 arc second data which is
much better than SRTM.
1/3 arc second data is even better but requires to split most tiles and haven't
done that yet.
groundtruth didn't work at all
Jeffrey Ollie schrieb:
> Does someone have wiki pages describing the best procedure to create
> contour maps for Garmins? It seems like a number of people are having
> some success but it doesn't seem to be very well documented. I'm
> working though trying to get groundtruth to generate .osm file
Does someone have wiki pages describing the best procedure to create
contour maps for Garmins? It seems like a number of people are having
some success but it doesn't seem to be very well documented. I'm
working though trying to get groundtruth to generate .osm files with
contours in them and the
Moin,
I tried a slightly modified patch provided by WanMil, where also mkgmap:mp_*=no
tags are added:
> the patch for the mp code does not remove any tags from the source
> polygons and lines. Instead it tags all mp-source lines and polygons
> with mkgmap:mp_source=yes and mkgmap:mp_created=no.
>
Version 1582 was commited by marko on 2010-02-21 18:25:46 + (Sun, 21 Feb
2010)
Revert r1581 after feedback from Dave F,
but use resolution=20 to match that of sport=*.
Let leisure=sports_centre have precedence over sport=*.
___
mkgmap-dev mailing
Hi Dave,
> This proves my point. You're amendment now excludes the fact it has a
> multi-use.
>
> I don't think it was a good idea to change for all cases based on one.
You are right, I did not think it through well enough.
> Are you saying your GPS labels it as swimming pool, even though it'
Hi Marko
Marko Mäkelä wrote:
> Hi Dave,
>
>
>> svn commit wrote:
>>
>>> Version 1581 was commited by marko on 2010-02-20 21:35:50 +
>>>
>> (Sat, 20 Feb 2010)
>>
>>> Move leisure=sports_centre below sport=*
>>> so that it will only be used when no matching sport=* is specifi
Hi Dave,
> svn commit wrote:
> > Version 1581 was commited by marko on 2010-02-20 21:35:50 +
> (Sat, 20 Feb 2010)
> >
> > Move leisure=sports_centre below sport=*
> > so that it will only be used when no matching sport=* is specified.
> Is this in points or polygons?
Points. I have not touche
svn commit wrote:
> Version 1581 was commited by marko on 2010-02-20 21:35:50 + (Sat, 20 Feb
> 2010)
>
> Move leisure=sports_centre below sport=*
> so that it will only be used when no matching sport=* is specified.
Is this in points or polygons?
I may have missed an earlier discussion, but
Hi,
based on some freely(?) available maps with DEM data and on "empty" DEM
files created by GMapTool I started to analyze the DEM subfile format.
With the little information I got so far (see
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/DEM_Subfile_Format)
I managed to write some rudi
Hello Mark,
> + new AccessMapping("motor_vehicle", RoadNetwork.NO_CAR),
>
> That's not enough because if motor_vehicle=no, you also want stop
> psv/taxi/emergency/hgv.
I see, although I would not stop emergency. In which order will the
access tags be processed then? What would happ
> Hi,
>
> Is there a way of disabling the multipolygon processing completely? I
> generate a routing layer that has no areas nor does it care about
> relations, so it would be nice if I could disable multipolygon
> processing to make things quicker.
>
Charlie,
I don't know an option for this. Co
On Feb 21, 2010, at 1:38, Daniela Duerbeck wrote:
> I know that generate-sea is still buggy but I cannot achieve any blue
> sea. I try to generate a routable map of the Canary Islands.
> With the mkgmap version 1580 I do not even get the coast lines.
> With 1484 I got blue islands on yellow sea.
Daniela Duerbeck escribió:
> Hi!
>
> I am relatively new to mkgmap but I searched the archive and found no
> answers.
> So I try to find help in this mailing list.
>
> I know that generate-sea is still buggy but I cannot achieve any blue
> sea. I try to generate a routable map of the Canary Islan
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 bu
Hello Marko,
+ new AccessMapping("motor_vehicle", RoadNetwork.NO_CAR),
That's not enough because if motor_vehicle=no, you also want stop
psv/taxi/emergency/hgv.
It's more like:
String mv = way.getTag("motor_vehicle");
if(accessExplicitlyDenied(mv)) {
way.addTag("motorcar", "no"
Hi Johann, Martin, Mark, all,
First, sorry for the duplicate post. I had to switch outgoing mail
servers, and did not realize that my first attempt at sending the
message was queued.
motor_vehicle is not understood by mkgmap
Actually, why not? If my memory serves right, mkgmap understands
2010/2/21 Mark Burton :
>
> Hi Marko,
>
>> > 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 ar
>
>> 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_vehic
19 matches
Mail list logo
