Hi
Good question, I was wondering that myself. It looks like with so few nodes
per area, we end up with some very thin areas that for example result in
the two areas on each side, plus two adjacent areas above, being included
in the extended bounds/overlap if a node is in the centre of the
Of course I forgot to attach the patch and examples... trying again.
..Steve
mkgmap-multipolypatch-v2.tar.gz
Description: GNU Zip compressed data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hey Steve
OK, if that is the case I was thinking that the overlap might be
better as a percentage of the size of the area. In areas where there
is a straight road that continues for miles and miles nodes might be
widely spaced, but that is unlikely in densely mapped areas.
Makes some sense,
v2
Space optimisation - no longer outputs per-subdivision 13-byte record if
the map contains no elements that have an extended type.
---
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended
types that are used on marine maps.
Extended
Hi
On 10/08/09 10:52, Chris Miller wrote:
Given that it's only when a relatively low number is given for --max-nodes
that we run into any trouble, maybe it's best to leave at 2000 for now. Is
there a reason why people would want to use such a low number? Smaller tiles
so more flexibility
Well I'm just saying that there was no particular thought in choosing
2000 in the first place.
I see. Obviously 2000 can't be working too badly since otherwise I'd assume
more people would have complained by now :)
For really old devices that have limited memory you may only be able
to load
Chris Miller chris.mil...@kbcfp.com writes:
For really old devices that have limited memory you may only be able
to load a few tiles at a time and then it would be more flexible to
have smaller tiles. But this is really from before OSM was started,
I've never had anyone complain that tiles
Hi,
2009/8/7 Marko Mäkelä marko.mak...@iki.fi
When the resolution of highway=residential was reduced, highway=service
should have been reduced as well. It looks odd to see highway=service
but not the highway=residential that they are connected to.
steve commited this change:
Dermot McNally derm...@gmail.com writes:
2009/8/10 Greg Troxel g...@ir.bbn.com:
For receivers with a 2GB uSD, I think one wants tiles pretty big. I
have 2009 vintage Garmin proprietary maps, and all of New England is in
2 tiles, and the .img I think are about 25 MB each. I also have a
Hi Steve/anyone,
Can someone please clarify exactly how DivisionParser.round(Area) is supposed
to behave? My understanding is that it is taking the area passed in and
rounding
the edges *outwards* to the nearest multiple of 0x0800. ie, the area should
get a little bit bigger in each
On Mon, Aug 10, 2009 at 09:14:59PM +0200, Ondrej Novy wrote:
[...]
It think we should set resolution for residential streets back to 21, now is
map just 'empty'.
If we want to have this set to resolution 23 we need to update more than
just service, but parking and track for example too.
Chris,
to behave? My understanding is that it is taking the area passed in and
rounding
the edges *outwards* to the nearest multiple of 0x0800.
Not _completely_ unrelated, I'm not sure if you know about this:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/002789.html
As far as I
On Mon, Aug 10, 2009 at 09:37:44PM +, Chris Miller wrote:
Assuming my understanding above is correct, here's how I think the rounding
methods should be implemented to give the correct rounding in all situations:
private int roundDown(int val) {
return val SHIFT SHIFT;
}
I would
13 matches
Mail list logo
