GerdP wrote
>
> Lambertus wrote
>> Great to see that a simple log can be so helpful. :)
>> Would be nice for splitter to be much faster with only a single pass on
>> a moderate pc (i.e. 8 gb ram), but I'm not complaining as it is...
>>
>> Running splitter r247 with the added logging parameters o
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
Henning Scholland wrote
> Am 29.11.2012 17:24, schrieb GerdP:
> It works fine now. Thanks a lot. If splitter makes always sure that no
> holes were created, --no-trim would be obsolete I think.
Fine :-) thanks for testing!
reg. no-trim: it is difficult to say what splitter should do if you don't
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
Lambertus wrote
> Great to see that a simple log can be so helpful. :)
> Would be nice for splitter to be much faster with only a single pass on
> a moderate pc (i.e. 8 gb ram), but I'm not complaining as it is...
>
> Running splitter r247 with the added logging parameters on my dev pc
> now, wi
Great to see that a simple log can be so helpful. :)
Would be nice for splitter to be much faster with only a single pass on
a moderate pc (i.e. 8 gb ram), but I'm not complaining as it is...
Running splitter r247 with the added logging parameters on my dev pc
now, will send the results tomorrow
GerdP wrote
> Hi Lambertus,
>
> thanks for the input. Yes, the log shows that the keep-complete functions
> require more then 5GB.
> This is okay, splitter has to save more information for this compared to
> r202.
>
> ciao,
> Gerd
Oh oh!
I looked again at this logs and wondered why some numbers
Hi Lambertus,
thanks for the input. Yes, the log shows that the keep-complete functions
require more then 5GB.
This is okay, splitter has to save more information for this compared to r202.
If you have more available heap, e.g. -Xmx7500m, you could use try a higher
max-areas value to reduce
r
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 polygon splitter will not create tiles that cover
large
If you can place yourself on the world, suddenly it is a smaller place.
Many happy returns & thank you all.
Lambertus wrote:
>Congratulations Steve and anyone on the list who contributed to this
>great project! Mkgmap has really become a remarkable application.
>
>On 26/11/2012 21:46, Steve Ra
Congratulations Steve and anyone on the list who contributed to this
great project! Mkgmap has really become a remarkable application.
On 26/11/2012 21:46, Steve Ratcliffe wrote:
>
> Hi
>
> On this day, 6 years ago, revision 1 was committed to svn.
>
> $ svn log -r1
>
Could splitter output a sensible polygon on runs without using one
afterwards? Geofabrik doesn't change their polygons often, so if one
runs it, splitter creates them, and one can reuse them for future runs,
that would be the best I think...
Maybe splitter could add 100m or 200m on generation, s
Hi all,
GerdP wrote
> So, I think this adds three points to my todo list:
> - make sure that trimming doesn't generate holes within the polygon (easy)
> - force overlap=0 if keep-complete is used (easy)
> - make sure that gereated tiles do not overlap the polygon too much (not
> that easy)
Regard
Hi,
don't remember anymore if this was already a topic here, I found
some similar reports, but didn't fully understand them.
I created a map of europe, about 911 tiles, containing only highways,
some very few landuses and cities as POIs.
The only errors I found in the log files are the usual are
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
On 29/11/12 12:19, Richard Welty wrote:
> java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm \
> --index \
> --gmapsupp \
> --remove-short-arcs \
> --description="Emergency Response Map prototype" \
> --add-pois-to-areas \
> --route \
> --family-i
Hi Lambertus,
Lambertus wrote
> Some results for r247, I hope it is of any use:
>
> This version is able to split the planet (r246 could not) but needs more
> memory then r202. Using -Xmx4000m an OutOfMemoryException occurs but not
> with -Xmx6000m.
>
> Number of stored ids: 19,330,031 requir
On 11/29/12 6:47 AM, Richard Welty wrote:
> On 11/29/12 5:26 AM, Steve Ratcliffe wrote:
>> | ah, i missed that. the change seems to have done it, address lookups in
>> | the nuvi now work.
>> Are you sure that made a difference? Although order matters it only
>> matters to options that affect how t
On 29/11/12 11:47, Richard Welty wrote:
> as far as i can recall, moving the input file to the end was the only change
> i made to the arguments. but i could be wrong.
OK. If there are any circumstances where changing the position of either
--index or --gmapsupp makes a difference then it is a bug
On 29.11.2012 12:57, Steve Ratcliffe wrote:
> Hi
>
>> There's something else that I think is highly non-obvious to new people:
>> there are a ton of options (no surprise), but the defaults are not
>> really useful. The norm among mkgmap users is to give a large number of
>> options, but for some
Hi
> There's something else that I think is highly non-obvious to new people:
> there are a ton of options (no surprise), but the defaults are not
> really useful. The norm among mkgmap users is to give a large number of
> options, but for some reason (perhaps trying to keep behavior
> consisten
On 11/29/12 5:26 AM, Steve Ratcliffe wrote:
> | ah, i missed that. the change seems to have done it, address lookups in
> | the nuvi now work.
> Are you sure that made a difference? Although order matters it only
> matters to options that affect how the following files are compiled.
> Both --index
>>> $ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar
>>> >>capitaldistrict-2012-11-23.osm --index --gmapsupp
>>> >>
>> > From mkgmap help:
>> >"Note that option order is significant: An option only applies to
>> >subsequent input files."
>> >So you should put your *.osm file last in the mkgmap ca
Some results for r247, I hope it is of any use:
This version is able to split the planet (r246 could not) but needs more
memory then r202. Using -Xmx4000m an OutOfMemoryException occurs but not
with -Xmx6000m.
Number of stored ids: 19,330,031 require ca. 2.04 bytes per pair.
1224726 chunks are
24 matches
Mail list logo
