Hi Gerd,
basically this describes my idea, just less quick&dirty ;-) I will give
it a try next weekend.
Of course for every map, you need a individual temp-DEM. So I don't seen
any issues with poly-cutted-tiles.
Henning
___
mkgmap-dev mailing list
mkgma
On 10.01.2018 20:33, Andrzej Popowski wrote:
> > i would be very defensive with interpolation in the case of
> > missing values.
>
> I got the same feeling. The best way to fill voids is to process whole
> HGT. And I believe that DEM providers already have done it, so any
> attempt at simple extrap
Hi all,
I don't see a reason to have this option at all. It should be set
automatically to 1 if either contour data or DEM is written. If this
data is in the map, you always want to have it and if those are not in
the map, you don't need it. Or am I wrong?
Henning
Also without show-profiles=1 MapSource and BaseCamp don't use DEM for
elevation of waypoints. Basically it's only used for routing and showing
the shades.
Henning
On 11.01.2018 17:52, lig fietser wrote:
>
> --show-profiles=1
> Sets a flag in tdb file which enables profile calculation in
>
Hi,
is there a reason for not listing --gmapi in the documentation (at least
on website)? Description can be simply:
Outputs map in gmap-format.
Btw: In overview map DEM, LBL, RGN and TRE don't follow map-id based
file name, but using 6234. In my case it should be 1005. NET and
NOD and a
Hi Gerd,
I like the idea to have somehow a map polygone limiting or extending the
'background'-map (means DEM, sea, background poly). How about --map-polygon?
So if I got it right, this develloping will end in non-rectangle shaped
map tiles?
Henning
On 10.01.2018 16:54, Gerd Petermann wrote:
> Hi
Hi Gerd,
I'm using only --overview-mapname=%famid%. For 'standard'-img map
file name is also set to 1005000.img
Will add also ..number. Thanks for the hint.
Henning
On 11.01.2018 21:06, Gerd Petermann wrote:
> Hi Henning,
>
> I'll add text to the doc and help.
> You you set --overview-mapnumb
:
> Hi Henning,
>
> yes, I also found this confusing when I added code for to write DEM for
> overview map.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Henning Scholland
> Gesendet: Donnerstag, 11. Januar 2018 14:22:24
>
Hi Gerd,
I think this would be best and additionally I would suggest to make the
polygon defined by user (as suggested in DEM-poly and precomp-sea
thread). As default I would limit overview map to the map tiles. Maybe
then we should name the parameter --overview-map-polygon=filename
I'm not sure,
ted with a proper polygon
> I would assume that this looks strange when you zoom in/out.
>
> I don't understand what you mean with maximizing/minimizing the polygon.
> Please explain.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftra
> ________
> Von: mkgmap-dev im Auftrag von
> Henning Scholland
> Gesendet: Freitag, 12. Januar 2018 13:16:19
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] The 0x4b background polygon in the overview map
>
> Hi Gerd,
>
Hi Gerd,
ok, maybe I was too fast. ;-)
I just tried to understand your Bremen example. You have splitted Lower
Saxony (Niedersachsen) into 15 tiles. Based on these 15 tiles you want
to let mkgmap create a map of Bremen by using a map polygon, which is
not following any of the splitted tiles. Lets
Something similar is already possible with splitter. You can create an
*.osm file with many polygons inside, each with tags name=* and mapid=*
(see attachment). splitter will give you tiles with 6234 and per
polygon a .args with list of necessary data tiles per map. That
args-file you can hand
Oh, forgotten to mention:
--polygon-desc-file=filename.osm you need to use for splitter.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej
For Africa it can be useful, as areas with drive on left /right are at
least roughly horizontal and vertical. Also you don't need overlapping
for this use case.
In general I also think, as soon as mkgmap can support non-rectangle
tiles, it will be better obsolete. Using non-rectangle ma
Small tiles are mainly caused by not well aligned polygons. I attached
you kmz with my splitter result. You can compare them for example in
josm. I just have realized the small tiles while testing in beginning of
DEM-support. While checking for broken img-files with 0kb I found
several others with
On 13.01.2018 00:43, Andrzej Popowski wrote:
> Is it this right-angled shape of polys required?
I'm not 100% sure, but somehow I remember Gerd told me it needs to be
rectangle shaped.
Hening
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
h
For overview-map it would be fine for me, but for detailed map I need a
block-size of 2k
Henning
On 13.01.2018 22:57, Gerd Petermann wrote:
> Hi all,
>
> I hesitate to commit this patch because I think that some users create
> overview maps > 64MB.
> Please check!
>
> @Steve: I see you are makin
Hi Gerd,
seems to work for me, but I also don't know what I should expect to see.
In BaseCamp/MapSource the map is still in rectangle shape with light
yellow coloured back ground in the area without data. Only difference
is, that there is no more mouse over, indicating the mouse is in
'Unbekanntem
With using --transparent I can't see any differences compared to older
mkgmap versions.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
regarding 1) I can create a list of existing tiles of Viewfinder (which
covers all land area so far I see). But it will be a long list. I
remember it's about 25000 files in total. So maybe it's easier to create
a polygon or at least take the list and let software create the polygon.
A
Hi Gerd
On 15.01.2018 15:05, Gerd Petermann wrote:
> Wouldn't it be better to change splitter so that it aligns tiles to HGT
> raster?
As long as we have rectangle map tiles, it would be a possible solution.
But in future we might have non-rectangle tiles or even tiles, not
splitted by splitter.
Hi Gerd,
thanks for merging it.
Hi Steve,
I tried it on maps, where I previously had problems with block size. Now
these maps compile well without increasing block size manually. Well done!
Henning
On 18.01.2018 19:14, Gerd Petermann wrote:
> Hi all,
>
> I've merged branch auto-block into r4070
Sorry, I forgotten to add this:
It seems the reason is that --polygon-desc-file is not working well any
more. So main reason is, that the map is getting bigger. You can see it
in last mails attached kml-files.
Henning
On 18.01.2018 22:33, Henning Scholland wrote:
> Hi Gerd,
> I have qui
Hi Gerd
I imported both kml-files to josm and added some taggs to make it more
clear.
landuse=grass -> split result based on r584 and also roughly same as
polygon used by splitter
landuse=industrial -> result with r585 and alignment to DEM. These tiles
should be in templates args
landuse =indust
Hi Gerd
I imported both kml-files to josm and added some taggs to make it more
clear.
landuse=grass -> split result based on r584 and also roughly same as
polygon used by splitter
landuse=industrial -> result with r585 and alignment to DEM. These tiles
should be in templates args
landuse =indust
Hi Andrzej,
I also suggest to make interpolation optional.
So far I don't understand your argument. I agree, compilation time is
not the only criteria. The question is, what is the benefit for the user.
For example: If accuracy of srtm is +- 10m and the difference between
with/without interpolati
https://en.wikipedia.org/wiki/Shuttle_Radar_Topography_Mission#Void-filled_SRTM_datasets
Henning
*
*
On 23.01.2018 20:59, Henning Scholland wrote:
> Hi Andrzej,
>
> I also suggest to make interpolation optional.
>
> So far I don't understand your argument. I agree, compilation time i
.org/web/20051024202307/http://www.geovista.psu.edu/sites/geocomp99/Gc99/082/gc_082.htm
>
> Gerd
>
>
>
> ____
> Von: mkgmap-dev im Auftrag von
> Henning Scholland
> Gesendet: Dienstag, 23. Januar 2018 14:09:17
> An: mkgmap-dev@lists.
Hi Mike,
are you sure, = needs to be replaced by : in read-config-file? I'm using
= and it seems to work. (At least I think/hope so)
Henning
On 23.01.2018 22:35, Mike Baggaley wrote:
> Hi Gerd, please find attached a patch to correct and improve the
> documentation of the --read-config command li
suming that files without voids have fewer errors)
> So, I think it would be good to have a list of those files that have voids.
>
> I'll see what is needed for this.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Henning Sc
Hi Gerd,
first I would suggest to wait for Steve is merging the block size branch
and just afterwards merge DEM branch to trunk. I think it's causing
trouble merging DEM branch before, as user might end up with errors.
Later start another branch for DEM-optimization.
I don't know how other global
Hi Gerd,
regarding tagisincomplete I would suggest to get rid of it. I can't
imagine any use of it.
For 2nd tagg it seems to be somehow useful. Maybe document it like '
Don't use in relation-style, is set to indicate line/poygon is part of
MP-relation'. The usage in relation-styles should be check
Am 29.10.2012 15:34, schrieb WanMil:
What can we do to avoid such a problem?
Maybe copy tags to polygon only if it's only one outer-way?
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgma
Am 04.11.2012 14:05, schrieb Gerd Petermann:
Please try again using e.g. only the tiles starting with 14.
Will do so.
@ all: I need an algorithm that uses a list like below and fills "the
rest of planet" with a small number of rectangles. There is no need to
find the smallest number, but the
Am 04.11.2012 17:29, schrieb toc-rox:
> GerdP wrote
>> ... I see --mixed in your parameter list. I can't say for sure, but I'd
>> say that the new algorithm may not work correctly with mixed input. It is
>> on my todo list to find out.
>> Do you really have a mixed pbf ?
> I think so - but I'm not
Am 04.11.2012 14:05, schrieb Gerd Petermann:
@ all: I need an algorithm that uses a list like below and fills "the
rest of planet" with a small number of rectangles. There is no need to
find the smallest number, but the result should be near.
Another idea:
detect problematic polygons or read p
Hi Gerd,
you said:
> for each node: calculate the area that contains it and save it in a map
So at the end of reading nodes, RAM knows, where a node is, or am I wrong?
Then it should be possible to check for each relation/way/node in which
tiles they have at least one node. The result would be,
Hi Gerd,
I will give it a try. Do you mean r212 with patch v2?
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
So I've tried it and stoped it after about 6 hours.
http://www.aighes.de/data/mkgmap.zip
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Oh, so I misunderstood you.
Thats the result with r221 and problem-file.
http://www.aighes.de/data/mkgmap.zip
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 07.11.2012 19:06, schrieb WanMil:
>> The profiling data shows that the CPU is most of the time
>> busy with the pbf read and write routines, so I doubt that your disk
>> is the bottleneck.
> From my experience profiling is a very time consuming (=> CPU
> consuming) task. So could it also be th
Am 07.11.2012 19:19, schrieb Henning Scholland:
> Am 07.11.2012 19:06, schrieb WanMil:
>>> The profiling data shows that the CPU is most of the time
>>> busy with the pbf read and write routines, so I doubt that your disk
>>> is the bottleneck.
>>From my
Am 09.11.2012 16:10, schrieb Minko:
> Thanks Gerd,
>
> If I understand it correctly, the option --problem-file=problem_polygons.txt
> is still needed?
> How can I save the report of the incomplete relations?
No, it isn't. --keep-complete calculates problematic objects
automatically. So it isn't n
Am 08.11.2012 01:42, schrieb GerdP:
> Hi all,
>
> r224 fixes this endless loop and other reported problems:
> - correct creation of pseudo areas
> - correct handling of nodes in relations
> - handle overlapping tiles
> - performance improvements:
> + reduce number of expensive intersects() for wa
Am 09.11.2012 16:27, schrieb Minko:
> Well, I tried to split the geofabrik extract from Sweden first without
> --problem-file
> and found a broken polygon of the Mälaren
> (http://www.openstreetmap.org/browse/relation/1433877).
> After I splitted it again with --problem-file (and this relation in
Hi Gerd,
it tooks a lot of RAM, but it works now for me. It took 2:30 h so its
ok. Thanks a lot!
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
log is available here: http://www.aighes.de/data/mkgmap.zip
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
I have a problem with a map containing different code-pages. A
problematic region for me is Middle Asia. There are parts with Chinese
names, Cyrillic names, Arabian names, Turkish namesand Hebraic names.
I create the map with code-page=1251 (means Cyrillic)and it works for
the Cyrillic p
Hi Gerd,
take th germany+.osm.xz
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
same procedure as last time:
http:/www.aighes.de/data/mkgmap.zip
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
I discovered a problem with missing objects and to much objects. I think
the first was almost wrong in earlier versions.
1104: 1800192,1406976 to 1968128,1681408
In this tile (north-western Turkey) there are missing two ferry-routes
(Yalta-Istanbul and Sivastopol-Istanbul). As I op
Am 16.11.2012 09:09, schrieb Gerd Petermann:
Hi all,
>
> 1104: 1800192,1406976 to 1968128,1681408
>
> In this tile (north-western Turkey) there are missing two ferry-routes
> (Yalta-Istanbul and Sivastopol-Istanbul). As I opened the tile in josm,
> I discovered also, that there are several o
Hi,
site-relation would become more and more importantbecause of detailed
mapping of objects in OSM. I think therefore it's necessary to copy
taggs from relation to a member with a special role. Is this already
possible in mkgmap-style? Otherwise it would be great if something like
this could
Hi Gerd,
r236 works fine for planet. Log: http://www.aighes.de/data/mkgmap.zip
Henning
Another thought: What about only analysing the ways, if they cross/leave
a tile and keep them in mind. Afterwards read all relations and check,
if they contains a way, which is kept in mind. So relations must
Am 17.11.2012 11:37, schrieb GerdP:
> Henning Scholland wrote
>> Hi Gerd,
>> r236 works fine for planet. Log: http://www.aighes.de/data/mkgmap.zip
> Yes, that really looks much better than the previous logs. The changes in
> the run times
> for the diverse passes meet my as
Am 19.11.2012 13:06, schrieb Chris66:
> Hi,
> what is wrong with these rules?
>
> When I activate the second rule I get a corrupted gmapsupp.img.
> (The first one is working ok).
>
>
> # Maxspeed (test)
>
> highway=* & ref=* & maxspeed > 1
>{ add display_name = '${ref} (${maxspeed})' }
>
> # h
Am 19.11.2012 17:23, schrieb GerdP:
> Hi all,
>
> I've committed r239 now.
> - r237 and r238 fixed o5m read and write issues
> r239:
> - don't calculate bbox for all ways of a multipolygon rel, instead try to
>find closed polygons and calculate the bbox for each polygon.
> - don't treat type=
Am 19.11.2012 20:22, schrieb Gerd Petermann:
Hi Henning,
I fear I don't understand what you mean.
> add --keep-complete= and write a
> list of problematic polygons to the given filename.
> --keep-complete shouldn't generate such a list
Do you mean that splitter should generate the list only if
Am 19.11.2012 20:17, schrieb Gerd Petermann:
Hi Chris,
this message appears if a way that is in the problem list is not
complete. It just means that splitter cannot "keep-complete" this way
because the input is already not complete. It is hard to say if that
is important for you ;-)
Splitter w
Am 19.11.2012 23:53, schrieb fla...@googlemail.com:
You describe an algorithm that uses the result of mkgmap processing to
"optimize" the position or size
of the tiles. Can you describe more detailed what splitter should
do with
this information?
Gerd
Mkgmap can Outpu
Am 20.11.2012 13:34, schrieb Marko Mäkelä:
> On Mon, Nov 19, 2012 at 10:02:43PM +0100, Henning Scholland wrote:
>> The problem is, that the complete way isn't rendered, if only one node
>> is missing. I don't know if it would be good, if mkgmap skip missing
>> nodes.
Maybe maximum length is 32 chars.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 21.11.2012 13:27, schrieb Thorsten Kukuk:
> Hi,
>
> with the current splitter/mkgmap, I have a flooded tile in norway.
> The reason seems to be multipolygon 96565, "Randsforden".
> The mulitpolygon is complete, but it is tagged as "natural=coastline".
> But it is inside of Norway, so no real coa
Hi Gerd,
just a question: Would it be possible to give splitter a polygon-file
and splitter generates tiles only for this polygon? Actually splitter
generates tiles always for hole bounding-box. It might be possible to
have some checks to polygon-file (rectangular, no to small parts). The
adva
Hi Gerd,
I don't know if you understand me correct. The resulting map should be
blue area in attached picture. I can cut OSM-data with osmconvert to
this polygon. If splitter generates an areas.list for the resulting
osm-file, splitter generates a areas.list for red and blue parts. It
would be
Am 25.11.2012 12:25, schrieb GerdP:
> Henning Scholland wrote
>> I don't know if you understand me correct. The resulting map should be
>> blue area in attached picture. I can cut OSM-data with osmconvert to
>> this polygon. If splitter generates an areas.list for
Am 25.11.2012 16:17, schrieb Richard Welty:
> On 11/25/12 9:51 AM, Thorsten Kukuk wrote:
>> I think this all comes down to calculate the shortest distance
>> between a point (the addr:housenumber) and a line (highway=*). You
>> can find some solutions on the net, like:
>> http://stackoverflow.co
Am 26.11.2012 12:14, schrieb Colin Smale:
>> WanMil wrote
>> Also, rels with type=boundary are no longer completed, only the part that
>> crosses a tile boundary.
> Is this going to affect anything in the index in the UK, where
> type=boundary is the norm for administrative areas (most other countr
Hi Gerd,
r247 works not as expected.
Let me explain it a little bit more. I would like to cut a area out of
planet-osm. This osmconvert does. After this splitter should generate a
areas.list out of this osm-extract (eg. dach.pbf, see dach.poly at the
end of the mail). This areas.list should aft
Am 26.11.2012 20:26, schrieb GerdP:
> Hi Carlos,
>
> Carlos Dávila-2 wrote
>> El 26/11/12 15:45, GerdP escribió:
>> I have just used r247 to produce a map of South America and noticed that
>> although it results in an smaller number of tiles for the same
>> max-nodes, tiles aspect ratio is not opti
Am 26.11.2012 20:44, schrieb GerdP:
> Henning Scholland wrote
>> --no-trim results in a coverage without gaps. Without no-trim you'll get
>> gaps in regions without data. Especially in water regions.
> OK, I understand. On the other hand, it gives the result that you want w
Am 26.11.2012 21:08, schrieb Henning Scholland:
> Am 26.11.2012 20:44, schrieb GerdP:
>> Henning Scholland wrote
>>> --no-trim results in a coverage without gaps. Without no-trim you'll get
>>> gaps in regions without data. Especially in water regions.
>> O
Thank you Steve, Thank you developer! Thank you for six years of coding
such a great tool. May be the seventh year will be the year of house
number-coding :-)
Also mkgmap could get a little bit more user-friendly. There are so many
parameter in --help=options and a beginner doesn't really know,
Am 27.11.2012 12:47, schrieb GerdP:
> Henning Scholland wrote
>> But not at all. If there are larger spaces with no data, no-trim=false
>> will create "ugly" looking maps. As you can see here:
>> http://www.aighes.de/data/scandinavia.png world.kml was cr
Am 26.11.2012 23:13, schrieb WanMil:
> Some small hints about your mkgmap configuration:
> * I propose to use precompiled sea files (e.g.
> http://www.navmaps.eu/wanmil/sea_20121020.zip). It's faster and takes
> less memory.
Hi WanMil,
is it possible to generate the precompiled files by myself? I
Am 27.11.2012 13:51, schrieb WanMil:
>> Am 26.11.2012 23:13, schrieb WanMil:
>>> Some small hints about your mkgmap configuration:
>>> * I propose to use precompiled sea files (e.g.
>>> http://www.navmaps.eu/wanmil/sea_20121020.zip). It's faster and takes
>>> less memory.
>> Hi WanMil,
>> is it pos
Am 29.11.2012 13:14, schrieb Felix Hartmann:
>>>--add-pois-to-areas \
>> R 8. But could be considered to be just making it work in the Garmin
>> format. Are there any downsides?
> Well it could lead to performance impact on the GPS device. For someone
> who doesn't need POI search, this opt
Am 29.11.2012 17:24, schrieb GerdP:
> Hi all,
>
> I've commited r249
>
> - overlap defaults to -1, it is set to 0 if keep-complete=true, else to
> 2000
> - using a bounding polygon forces no-trim=false. Splitter makes sure that no
> holes are created within the polygon
> - if using a bounding pol
Am 30.11.2012 00:47, schrieb GerdP:
> reg. no-trim: it is difficult to say what splitter should do if you don't
> specify a bounding polygon. Do we only care about holes that
> are enclosed by other tiles or do we also not want gaps between two
> tiles? The latter typically happens when you have so
Am 30.11.2012 10:04, schrieb GerdP:
> Hi all,
>
> r250 fixes a performance issue that shows up if you use --keep-complete in
> combination with a max-areas value which is lower than the actual number of
> tiles (including the "pseudo-tiles").
>
> Open problems/questions regarding complex bounding p
Hi,
take a look at
http://wiki.openstreetmap.org/wiki/Mkgmap/help/options
It wont be perfect, because it might not be written for beginners. If
there are Ideas how to make mkgmap-wiki-pages more useful, be free. It's
not really maintained and there is no clear structure.
Henning
__
Am 04.12.2012 10:17, schrieb WanMil:
> What happens with a tile that has a 179 longitude or latitude?
> mkgmap compiles it only if
> * --transparent is set
> * --bounds is not set
> * --precomp-sea and/or --generate-sea and/or --coastlinefile is not set
I agree, that typical, at least one of the ab
Hi Gerd,
what about a check, if left=~-180 or right=~180, if this is really the
leftest|rightest part of the map, or if it continues on the other side
on anti-meridian. If so, divide bounding-box at anti-meridian into two
parts and calculate tiles for these two bounding-boxes.
Henning
So there are several cases:
1: several distinct areas in oneinput-file (eg Iceland and Germany or
France and all there islands)
-> splitter should stop and ask the user to use al polygon-file or
create a polygon-file itself and warn user, that h did so
2: Map crossing 180/-180
-> split bounding
Am 05.12.2012 12:18, schrieb GerdP:
> Henning Scholland wrote
>> So there are several cases:
>>
>> 1: several distinct areas in oneinput-file (eg Iceland and Germany or
>> France and all there islands)
>> -> splitter should stop and ask the user to use al poly
R is just a string. ${rcn_ref} means the value of rcn_ref. So if
rcn_ref=1 The result is R1.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 06.12.2012 13:58, schrieb gbbickerton:
> Thankyou
>
> I am new to this and have been looking at other styles to try and figure ouy
> how things work
> I am trying to find a way to have the name of a cycle route alongside it
> together with a box with the route number so far I can get one or the
Hi Steve,
here are my thoughts about it:
--latin1 should be removed it's the same as --code-page=1252
--index default on could break map-creation on older machines, don't
know if this would be good
--createbounds keep or put it in a separate tool, maybe together with
create precompiled sea
-
Am 07.12.2012 00:42, schrieb Greg Troxel:
--check-foo:
replace with --warnings/--nowarnings, defaulting to warnings. Put in
some output warning file, with a prefix by warning type for grep.
Don't worry about enabling/disabling them individually.
I think such warnings shouldn't be defaul
Am 07.12.2012 13:42, schrieb gbbickerton:
> I was unfortunate to use some line types which do not show in Basecamp
> initially which caused a huge amount of confusion trying to figure out what
> was wrong with my code, perhaps mkgmap could test for unusable types.
If there is a sytax-error, mkgmap
Am 07.12.2012 11:12, schrieb michael lohr:
> --ignore-turn-restrictions should be kept for pure walking/cycling maps,
> unless this can be achieved in the style. i never tried but something
> like type=restriction {delete type} could maybe replace it.
I think it's the better way, to move it into
It's a question of parsing the data.
You (means mkgmap) have to rebuild superroutes, till there are only
way-member in it.
Eg:
parse tile and read all relation (maybe store in RAM)
if relation_A contains relations_B, replace all relations_B in this
relation_A with the objects the relation_B1..
Am 08.12.2012 19:04, schrieb Felix Hartmann:
> --location-autofil :: If I understand right, it is still a backup if
> bounds fail. I currently use --location-autofill=bounds,is_in,nearest
> because I want is_in first, secon nearest to provide the location if the
> precompiled bounds fail. Maybe mak
Am 10.12.2012 12:32, schrieb Steve Ratcliffe:
> Thanks for the explanation, If there is no option that is clearly
> superior in all cases, then there is no problem in having more than
> one, it just falls to documentation to explain which one to use in
> which case.
>
> What sub-options to generate
Am 10.12.2012 13:34, schrieb Steve Ratcliffe:
> Hi Felix
>
> Thanks for your thoughts.
>
>> --ignore-maxspeeds , Strong Objection. For a bicycle map it is really
>> needed. I don't want mkgmap messing around with maxspeeds. It's also
>> about performance, why calculate something if it's not needed
Hi Felix
Am 10.12.2012 14:20, schrieb Felix Hartmann:
road_speed=4 === set current road_speed to 4 or lower - if maxspeed is
lower, but not higher (new behaviour)
You mean: road_speed>4 {set road_speed=4 }
road_speed_fixed=4 == set current road_speed to 4 no matter maxspeed,
recommended spee
Hmm...ok so you want to add eg. road_speed_max=4 and after all style
processing mkgmap should convert maxspeed=* to road_speed and take care,
that road_speed has a maximum value of 4.
I think you wont need something like road_speed=* to set it fix (actual
behaviour, I wouldn't change this)and c
It would be quite hard to understand, if you have a part of it in
action-rules and a part in []. So I would like to keep it in []-part.
Also I don't like special tags very much.
We'll need a maximum for road_speed, a minimum, a fix value (actual
road_speed with --ignore-maxspeed) and a default
Hi Gerd,
I think writing a areas.poly isn't needed, if --split-file=* is used.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
201 - 300 of 532 matches
Mail list logo
