Hi,
I think that safe limit for subtype is 0x1F, but for many types values
up to 0x3F can be used.
I have creates some test maps and found that following values work:
POI_type_start, POI_type_end, subtype_less_than
0x01, 0x11,1
0x14, 0x15, 0x40
0x16, 0x1D, 0x20
0x1E, 0x1E, 0x40
0x20,
Hi Gerd,
in my opinion this is valuable change and should be merged to trunk. I
would even suggest to use admin level 2 as default. This would lead to
compatibility between maps, even if authors are unaware of this feature.
--
Best regards,
Andrzej
Hi Gerd,
I have imported your routes to BaseCamp and then sent to Dakota. It
looks ok. When I select route as a destination, Dakota shows route for a
moment as a straight line and then recalculates on roads, see pic
"go-to". If I start navigation, then Dakota calculates again, adding a
leg
Hi Gerd,
one more note: all routes in my test has been calculated in devices. I
turn on GPS simulation, set current position somewhere inside map area,
then browse map and point a destination.
If you transfer routes form Mapsource, then maybe you should force
recalculation in device?
--
Hi Gerd,
In my test, I have used MapInstall to create 3 separate img for GPS.
I have run your scripts, then copied 2 created gmapsupp.img to GPS (I
have renamed second one as gmapsup1.img). It works correctly for me,
both in nuvi and in Dakota. See attached picture form Dakota.
I have no
Hi Gerd,
yes, there are messages like this:
SEVERE (WrongAngleFixer): pbf\be\71282723.osm.pbf: country boundary node
is replaced by node with non-equal coordinates at
http://www.openstreetmap.org/?mlat=50.920098=2.593385=17
SEVERE (WrongAngleFixer): pbf\be\71282721.osm.pbf: country boundary
Hi Gerd,
> I am not yet sure what to do with roads that share multiple nodes with
> country borders.
I guess, some optimization would be beneficial. This is probably a case,
where road goes along a border. If there is a series of consecutive
external nodes, you could leave only first, last
Hi Gerd,
I have attached a script for creating a test map. It is Benelux, but
created from 3 separate countries. It works like 3 separate map.
You need 3 extracts form geofabrik.de. You should correct paths to data
and tools in scripts.
The result of your algorithm is promising. There is
Hi Henning,
does your style include 'inc/address' before rules for boundaries?
Default style doesn't make it easy to use mkgmap:country, which is
actually generated after all rules in finalize stage.
--
Best regards,
Andrzej
___
mkgmap-dev mailing
Hi Bernhard,
routable roads contains "nodes", which can be junctions or address
points. Only some nodes are marked as "external", mkgmap creates them at
borders of tiles.
My idea is about creating some additional external nodes, that should be
always at the same position, regardless of the
Hi,
I'm not sure, if I have already written about this problem, sorry if I
repeat myself.
Routing between maps require external nodes at the same position on both
maps. With rectangular tiles external nodes are created only at borders
of the tiles (at least this is what I would expect).
Hi Gerd,
> A complete tile would already be too unprecise.
I agree, but I think it would be better than nothing and it looks like
to be quite easy to implement. I like that this approach automatically
takes account of used style and map properties like labels, routing or
DEM settings.
And
Hi Gerd,
> Split planet file using the grid, run mkgmap with the desired options
> for each grid element, store the size of the img file, and normalize
> these values to a weigh factor.
My suggestion: add an option to splitter, which shows a path to a
compiled map. Then splitter can read all
Hi Randolph,
what do you mean by "ways"? Any line, road with an address, road used
for routing? I don't remember if I ever spotted similar problem.
On the other side, I think splitter can be better tuned for current
mkgmap. I get impression, that splitter is designed to make a good work
Hi Gerd,
your patch is working, thanks for a quick solution!
The example of problem was from my address map, where for each house
number I create a small road. For Kartuska there are numbers like 75,
75A, 75B, 75C. Since Garmin doesn't allow for literal in house number,
there are multiple
Hi,
when compiling a map from *.mp sources, address search doesn't work as
expected in Mapsource. I have prepared a set of data for testing:
http://files.mkgmap.org.uk/download/433/test-index.zip
I can't get correct results, when searching for address:
house number: 75
street: KARTUSKA
city:
Hi Gerd,
I haven't followed this discussion, sorry if I repeat a case or problem
is already dealt with.
When you use highways defined as area for routing, then area border is
converted to road. Quite often there are multiple areas with common
border. This common border can lead to duplicate
Hi Ticker,
> as long as the start and/or end points are only a few streets away
> from the ferry termini
This could be because of service roads leading to a ferry. That kind of
roads are the last resort for a route and usually at the endpoint only.
They are probably ignored, when calculating
Hi Joris,
> Is there a way to limit the number (or extend the distance) of highway
> shields in basecamp?
Try to change setting in BaseCamp, menu Edit -> Options -> Display - Labels.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Ticker,
all these ferries are used for routes in BaseCamp. 2 of them only for
pedestrian routes.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
records in MPS subfile contains FID/PID for each tile and these values
are compared to FID/PID from TYP. Quite possibly only FID is compared.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Manfred,
> So it seems to me, that there is no really guide line how to put in
> the value of height or elevation in the osm map.
Actually there is, exactly like you see in default style. This is a
format for objects that support elevation, like for example peaks or
contour lines. For
Hi Gerd,
this is a problem of Mapsource. Transparent maps with routing work well
in GPS.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Nick,
> Very odd that transparency affects routing !
This is only a peculiarity of Mapsource. You should get routing on
transparent map when used in GPS. Transparent maps with routable trails
are quite common.
--
Best regards,
Andrzej
___
Hi Gerd,
wow, I'm impressed!
In my notes I have bit 0 described as "basemap". I don't know where I
have found this info or how credible it is.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Steve,
I observe the same - on Garmin's maps each tile gets SRT and MDR get its
own SRT too. My general assumption is that GPS sorts subfiles by name,
so 12345678.SRT is used only for 12345678.LBL. If there is 1234.MDR
then it can use only 1234.SRT. If there is .SRT that
Hi Steve,
what about SRT subfile? I think SRT is only a part of an MDR (or a part
of a tile). It is associated to MDR by its name. See code in
GmapsuppBuilder.java:
if (createIndex) {
MdrBuilder mdrBuilder = addMdrFile(familyId, info.getSort());
mdrBuilder.onMapEnd(info);
}
Hi Franco,
there are 2 weird things in your maps. First is a subfile SRT, which
doesn't belong to any tile or index. It is present in both files, bad
and good img. It is probably ignored by GPS.
Maybe mkgmap writes SRT even if MDR is not present?
Second distinction is that bad img is
Hi Franco,
there is a limit for maximum number of tiles, that GPS can process. It
depends on device, I think it could be like 2000 or 4000 tiles. Is your
map that big?
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Gerd,
TDB doesn't need much info. There is a function FileInfo.getFileInfo(),
which seems to provide all what is needed. You probably would have to
comment parts of code, which deals with overview map and mdr index, but
it is too difficult for me to find these parts in all sources. So I'm
Hi Gerd,
I'm not sure, what are you asking about. Are you trying to create a TDB?
I think this should work if you bypass creating of overview and mdr.
If you only want to convert map to gmap format, then Garmin's
MapConverter should work.
--
Best regards,
Andrzej
Hi Gerd,
> It might be that MapSource is much more restrictive when the tdb file
> says that the map is not from Garmin, e.g. it is not lockable or
> whatever MapSource might use to detect that.
This is the byte before "lowest map level", locked maps get value 1 there.
I think you could use
Hi Gerd,
I guess basemap is overview map. 0x4A objects are derived form
backgrounds of detailed tiles, but with resolution of overview map, it
would be difficult to guess, if background overlap or not.
I hope extending values written to TRE will work.
--
Best regards,
Andrzej
Hi Gerd,
I have some questions.
Is TRE area bigger than DEM area or tiles overlap but still DEM area is
bigger than TRE? It looks like overlap is 4 Garmin's units, this is less
than DEM raster size.
> The next interesting point is that the 0x4a polygons of these two
> tiles do NOT overlap.
Hi Gerd,
> I only have one routable map with DEM data
See this nice post by moderator on Garmin Forum:
https://forum.garmin.de/showthread.php?49979-TopV7-Routen-aus-markierten-Wegen=247707#post247707
These maps work in BaseCamp, when placed on pendrive.
--
Best regards,
Andrzej
Hi Gerd,
> The wiki [1] describes these 7 bytes as
> "byte:0 has copyright text,byte 1: has 0x53 text : byte 2:if 1 then
> bytes 3_7: an unknown total (density) "
For gmaptool I have assumed following meaning of these data:
byte 0 - always 1
byte 1 - region (always 1)
byte 2 - subregion (always
Hi Gerd,
I have compiled baddem6 and I confirm your observations. I have no idea,
what to do with it.
I have found a minor error, see attached patch. Mkgmap calculates
min/max heights for header using values form tiles, which have bitstream
data. This is wrong for flat surfaces, which have
Hi Gerd,
maybe this is a problem of overlapping of DEM form different tiles? Or
maybe size of DEM area is calculated incorrectly?
Could you upload an example? I haven't used dem-poly on my maps and
never noticed this problem.
--
Best regards,
Andrzej
Hi Gerd,
> Do you think that it can cause trouble when a sub division from tile A
> overlaps another from tile B at level 1..7 ?
I don't think there is a problem with overlap. I'm only stating, that
splitter idea of "resolution" is a clever one, since it can lead to no
overlap at all.
--
Hi Gerd,
I say layers, but maybe you call them levels, like in option:
levels = 0:24, 1:23, 2:22, 3:20, 4:18
If splitter uses --resolution=18, then for the case above, layer/level 4
can get exactly the same bounding box as layer/level 0. If you use
arbitrary resolution, then there were some
Hi Gerd,
I think resolution in bits is a clever idea. This way we can get a tile,
where border of all layers is exactly the same. Maybe this is not
requirement for a map, but it seems to be a neat solution.
--
Best regards,
Andrzej
___
mkgmap-dev
Hi Gerd,
option probably won't be useful. Maybe you could change it to some kind
of alternative to --resolution, where value is set in degree, but it
still wouldn't look useful to me.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi,
I have added more algorithms for testing, patch is attached. Patched
mkgmap recognize following values for x-dem-interpolation:
bilinear
bicubic
bicubic-spline
bicubic-catmull
bicubic-hermite
I have prepared new set for testing:
http://files.mkgmap.org.uk/download/408/interpolation2.7z
Hi Gerd,
thanks for noticing :)
I hope anyone testing these maps will correct options for bicubic-spline.
Now there is a difference. Bicubic-spline looks more smooth than
bilinear, but the heights of peaks is lower, which is unexpected.
So again, bicubic looks the best.
--
Best regards,
Hi Gerd,
thanks for option. I have prepared a set for tests:
http://files.mkgmap.org.uk/download/407/interpolation.7z
This set creates maps with different resolutions and interpolations. I
have created a direct route and compared height profiles created with
different maps. Here my
Hi Gerd,
maybe we can wait a bit with optimization? What I would like to get is
an option for mkgamp, that will allow for testing quality of all these
versions of interpolation. For now we have bilinear, bicubic and bicubic
spline. This all could be included in code and selected by user.
--
Hi Gerd and Henning,
> If accuracy of srtm is +- 10m and the difference between
> with/without interpolation is +-1m, then it's definitely not worth
> spending any effort on interpolation.
This is not like interpolations error is placed within source data
error. This error is added to data
Hi Gerd,
there are different kind of bicubic interpolations. I'm not good at this
math, I think the previous version was actually bicubic spline
interpolation. See other possibilities here:
http://mrl.nyu.edu/~perlin/cubic/Cubic_java.html
I don't know, which type of spline or cubic
Hi Gerd,
see example form BaseCamp:
http://files.mkgmap.org.uk/download/406/at2.png
I do some zooming in/out at it appears.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Gerd,
I have looked at Adria Topo and there is the same problem with small
islands. Maybe it is not mkgmap's fault?
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi,
on my maps I use 4 layers of DEM. The problem with shading appears
mostly, when using medium or low detail level in Mapsource, probably
when Mapsource use layers with lower resolution. Pressing Ctrl-G shows
overview map and I think it always display correct shading.
Other peculiarity is
Hi GErd,
if you use DEM with voids, voids are visible as areas with no shading.
When you move mouse cursor over voids, Mapsource doesn't show height.
Now this is unexpected: both areas can be misaligned. It looks like
there are different procedures for calculating shading area and DEM
heights
Hi,
I'm attaching a next patch for bicubic interpolation. It include
following changes:
- some errors corrected,
- more statistic of interpolation,
- changed condition for applying bicubic interpolation.
In this version bicubic interpolation is applied, when required DEM
resolution is not
Hi Gerd,
> Bicubic expects grid [-1,0,1,2] X [-1,0,1,2]
> fillArray uses [0,1,2,3]X[0,1,2,3]
That's the reason for "-1" in following code:
h = rdr.ele(xLeft + x - 1, yBottom + y - 1);
eleArray[x][y] = h;
I have corrected some errors, will post a new patch soon.
--
Best regards,
Andrzej
Hi Steve,
it was my first impression, that MDR got only big blocks, but you are
right, there are all sizes used. Now that I have looked more carefully,
I see some inconsistency. MDR img has always the same structure, I would
suspect, that block size increase with file size, but it is not
Hi,
here is my version of mkgmap for tests:
http://files.mkgmap.org.uk/download/403/mkgmap-dem-tdb-r4071-bicubic.zip
Changes are following:
- dem-dists values are rounded to 16,
- DEM coordinates are multiples of dem-dists,
- DEM values are calculated with bicubic interpolation for layers with
Hi Gerd,
> Maybe you can create a 2nd branch so that others can try the
> different results?
I hardly know java, have no IDE for work or any experience in SVN.
Basically I can tweak your code and compile it with ant. I could post
compiled version if there is any interest.
--
Best regards,
Hi Steve,
I have compiled several maps with r4070 without even noticing, that it
include your new code. I think it means, that you have done a good work,
thanks!
I have looked at block sizes and all is reasonable. Tiles are usually 2k
or 4k, ovm_* are 512 or 1k, MDR are 8k or bigger. I
Hi,
I still observe the first problem with small rectangles without shading.
But I see it only when displaying small islands on a see. Like for
example PrÃncipe Island or Ascension Island.
Could it be, that processing sea level or voids around island could
cause similar effects like polygon
Hi,
quick comparison between r4068 original and r4070 with bicubic
interpolation. Both use pbf aligned to HGT and the same 3 arc degree HGT
with many voids.
http://files.mkgmap.org.uk/download/401/orig-aligned.png
http://files.mkgmap.org.uk/download/402/bicu-aligned.png
DEM shading moved
Hi Gerd,
I have included bicubic interpolation created by Ken Perlin:
https://github.com/mlevans/pretty-heatmaps/blob/master/DensityArrayCreation/src/DensityArrayCreation/Bicubic.java
Bicubic interpolation is used only for layers with good resolution (3
arc seconds or better). For other cases
Hi Gerd,
> What makes you think that 0,0 is used instead of the upper left cornen
> given in the DEM section header(s)?
In Garmin's DEM coordinates are always a multiple of DEM pixel size
(dem-dists). The result is, that all DEMs data are aligned with 0;0. It
makes easy to join different
Hi Gerd,
> I'd prefer to use unmodified dem-dist values for now, besides that the
> unit tests don't compile with it.
I'm trying to get DEM looking like in Garmins img. The actual rounding
in code can be disabled, but then it would be up to user, to set correct
distances. I don't know, if
Hi Gerd,
my current opinion is, that aligning to HGT won't work. The way Garmin
sets coordinates in DEM suggests, that all DEM is aligned to coordinates
0;0. Since pixel distance for DEM can be set exactly as in HGT, the
farther form 0;0 the bigger misalignment. Then at some point could
Hi Gerd,
I have prepared patch according to these guessed rules. It rounds
dem-dist and shift coordinates of top-left corner of DEM areas. Since
dem-dist doesn't correspond exactly to HGT, interpolation is always active.
I think there could be 2 ways to improve DEM quality. Interpolation
Hi Gerd,
I have executed your script and looked at maps. I have tested them with
artificial HGT too. Only the original-unaligned map has DEM at wrong
position. It is moved by about 0.00033 degree right and down.
I looked at offset calculated as (DEM coordinate)%(dem-dist) and only
for this
Hi Gerd,
I have looked a bit at Garmin's DEM and I have some guesses.
* Coordinate resolution for DEM is 28 bits. Since it is shifted to the
left, 4 lower bits are always 0.
* The same goes for pixel distance, lower 4 bits should be 0. This is
the reason, why Garmin uses 3312 (CF0) instead
Hi Gerd,
I have tried to verify, if aligned DEM is correct. I think algorithm
have passed positively 2 tests:
- reading height from map gives correct values,
- changing bbox of source data doesn't change resulting map, even if it
changes offset applied for aligning.
The aligning changes a
Hi Gerd,
I have compiled my 2 tiles and the one you found as a problematic. Now
with SRTM 3 seconds. I have used mkgmap 4068 with your patch. It all
looks good. Shading is the same on all maps, peak DEM height for a
mountain is the same and nearly on the same position, which is at HGT node.
Hi Gerd,
I have prepared artificial HGT with both resolution and tested both. I
haven't tested with real HGT 3". I will check this too.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Gerd,
> So I tried other bboxes, and found this one:
> 2902: 2291022,918105 to 2297489,946049
I have compiled this tile and found no difference, it looks the same as
my tiles. DEM heights are the same.
I have prepared dummy HGT with checkerboard patter. It makes quite easy
to verify,
Hi Gerd,
I have done 2 kind of tests, both with mkgmap patched with your patch
for aligned HGT.
Fist test is more or less the same what you propose. I looked for a
round peak on a map and then searched for the highest value of DEM on a
peak, moving cursor around. With zoom 20m, I tried to
Hi Gerd,
I have tried to align pbf bbox with HGT. I have ceated 2 maps, one with
god alignment and second with left and top edge moved by 1/2 HGT pixel
size. I have used HGT with resolution 3600, so the movement was about
15m. I think shading is the same on both maps. There is no obvious
Hi Gerd,
thanks again, America South compiled OK.
A tile with lower edge at 0 compiles properly, but don't you expect the
same problem with lower or right border?
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Gerd,
I use SRTM3 v3, so map can be different, but I'm surprised by difference
in details. That's why I wanted to recompile map.
I can see shift in shading when aligning DEM, I told so in my first
post. But I rather don't notice that shading doesn't fit map features.
Probably this
Hi Gerd,
I have tried to compile South America and tripped on another crash. This
is version 4065, it crashes regardless if HGT is present or not.
http://files.mkgmap.org.uk/detail/395
java.lang.ArrayIndexOutOfBoundsException: 5
at
Hi Gerd,
on your pictures it looks like shading form extended DEM doesn't match
map features. Is it HGT with resolution 1200? Shading looks more
detailed than on my map, which uses DEM created by BuidDemFile. I have
to recompile my map to compare.
I have done different test. I have analyzed
H Gerd,
> I wonder if we can create a list of files that can exist
I believe that SRTM + Viewfinder Panormas cover full area of lands,
including South Pole (could we compile map of Antarctica?). I wonder if
you could use precompiled sea for checking if HGT is needed.
I wouldn't bother with
Hi Gerd,
I guess your code already makes sure, that whole area is covered by DEM.
So yes, extending bottom/right is not necessary.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Gerd,
thanks, I have compiled Africa without problems.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
addition: mkgmap compiles this example, if I remove --dem-dists.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
I have uploaded example at
http://files.mkgmap.org.uk/download/392/test-crash.7z.
java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Unknown Source)
at java.nio.DirectByteBuffer.getShort(Unknown Source)
at
Hi Gerd,
> you just want to achive that the calculated postions are as close as
> possible to the positions in the hgt file
Yes. Linear interpolation is averaging too. If DEM can use exact values
form HGT, then there will be no averaging. Even interpolated values near
HGT node should be the
Hi Gerd,
> why you don't use the modified area for the hgtConverter as well?
I need HGT resolution first. I guess resolution comes after
initialization of hgtConverter. Probably area for hgtConverter should be
expanded, or maybe initialized with a bit bigger area?
--
Best regards,
Andrzej
Hi Gerd,
I have attempted to reduce interpolation, when DEM pixel size is the
same as HGT pixel. I have stretched a bit area of DEM, so edges are
aligned with HGT. I'm attaching a patch.
Resulting map looks similar, only shading has moved a bit. I'm not sure
if this is the result of
Hi Gerd,
do you have overview for Winter Activity Map? I have never seen Winter
map for PC, only gmapsupp.img. Maybe it is an overview created by
GMapTool, check copyright in TRE.
I have included procedure for creating empty DEM in GMapTool, which is
using different distances. Actually it
Hi Gerd,
> 1) don't add DEM to overview map (a work around)
Maybe it would work, but I remember getting problems with overview
without DEM (I forgot what it was, maybe even not because of DEM?). I
think it would be better to add what I call "empty DEM" instead.
The empty DEM layer contains
Hi,
I got once overview bigger than 32M and I had to decrease DEM
resolution. 64MB seems quite big for an overview.
Anyway, I have provided this patch, because I have finally found the
reason for big MDR sizes. I hope at least this one correction can be
moved to trunk.
--
Best regards,
Hi Gerd,
now I get the problem. What you see is DEM from overview map. I don't
think you can remove that. I have looked at available Garmin maps to
compare, and there are 3 solution:
- Leave jagged DEM, overview map covers a bit more area, so jagged
border is like 700m from tile background.
Hi Gerd,
I don't think that any changes in overview are needed. If you zoom into
detailed map, then overview is unimportant.
I have installed Winter Activity Map in Mapsource using GMapTool. The
overview map is very simplified, it contains objects 4A and 4B as
rectangles and no DEM. Still I
Hi,
here is attached temporary fix for block-size. List of changes:
* Default block size for img set to 1k. This allows for img up to 64MB.
User can change this value with option --block-size.
* Block size for overview map fixed at 1k. Not changeable by user.
* Block size for MDR fixed at 16k.
Hi Henning,
looking at your files, I see that small rectangles are forced by
overlapping areas.
I think restriction for poly are the same as for option --polygon-file,
quote from doc: "If the polygon area(s) describe(s) a rectilinear area
with no more than 40 vertices, splitter will try to
Hi Henning,
you are right, using splitter is a valid alternative to my process.
Is it this right-angled shape of polys required? And where are created
small tiles, around any border or only on overlapping areas?
--
Best regards,
Andrzej
___
Hi Henning,
> --polygon-desc-file=filename.osm
Thanks for info. That's very interesting. Actually I would like similar
processing for mkgmap, since I'm satisfied with standard splitting.
But I see a good uses for this feature. I can create polygons for drive
on left and drive on right
Hi Peter,
Viefinder-Panoramas files not only contains voids but some serious
errors too, like depressions 1km deep. At least they had some years ago.
SRTM data version 3 are mostly void free, but I can see some voids for
example in Nepal. Currently you need a login to get SRTM data. I think
Hi Henning,
> you should be able to split Europe once and then just let mkgmap
> calculate all the country maps based on the boundary polygons
I'm doing something similar for my maps. I create a map of a continent,
for example Africa and then I execute mkgmap with list of img to create
Hi Gerd,
using poly to clip background could be a way to create irregular maps.
There are some caveats.
Background doesn't clip map data, they will be still visible. The proper
way would be to clip data too.
Detailed tiles and overview map have different resolution and usually
their edges
Hi Gerd,
great, thanks for quick solution!
I haven't looked at code but I think mkgmap builds internal poly from
tiles area, when dem-poly is missing. So DEM in overview is still
clipped. I haven't noticed artifacts in this case, was it different form
irregular poly?
--
Best regards,
Hi Nick,
DEM in GMP should be the same. The difference is, that in DEM subfile
headers starts at 0, but in GMP header is at address contained at offset
0x2D. If you want to analyze DEM then algorithm is something like that:
char *subfile
int offset;
if (typ == DEM)
offset = 0
if
Hi Gerd,
probably all Garmin's map have irregular background. You can look for
example at old Winter Activity Map:
https://static.garmincdn.com/shared/de/custom/winter2013/_download/winterkarte.zip
It is GMP, but DEM data should be the same.
--
Best regards,
Andrzej
101 - 200 of 709 matches
Mail list logo
