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 th
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
http://www.mkgmap.org.uk/mailman/listinfo/mk
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 sen
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 t
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 l
Hi!
I am using an alternate splitter (built into OSM Composer) to prepare
tiles for processing with mkgmap. It works rather well, except when it
comes to the splitting of polygons involved in multipolygon relations.
A possible result of splitting is a large polygon split by a tile
boundary i
On 10/08/09 14:29, Nop wrote:
> What is the expected strategy for splitting a polygon with multipoly
> relations into several parts within one tile? How does splitter handle
> this? Has there been some work around this area recently?
The patch I forwarded onto the list this morning was dealing
w
Hi!
Steve Ratcliffe schrieb:
>
> On 10/08/09 14:29, Nop wrote:
>> What is the expected strategy for splitting a polygon with multipoly
>> relations into several parts within one tile? How does splitter handle
>> this? Has there been some work around this area recently?
>
> The patch I forwarded
Chris Miller 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 were too big, i
2009/8/10 Greg Troxel :
> 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 2002
> or 2003 vintage receiver and proprietary map data, an
Hi,
2009/8/7 Marko Mäkelä
> 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:
-highway=residential | highway
Dermot McNally writes:
> 2009/8/10 Greg Troxel :
>
>> 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 2002
>> or 2003 vintage rece
Greg Troxel wrote:
Dermot McNally writes:
2009/8/10 Greg Troxel :
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 2002
or 20
An OpenStreetMap Garmin map is much larger: 3.45 GB is the size of the
231 tiles covering the whole world based on the planet file from July 23rd.
Felix Hartmann wrote:
> I becomes pointless therefore to be able to write mapsets bigger 2GB
> (City Navigator Classic Europe and newest CN are ove
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 direction.
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 kn
Hi!
I am just having my first look at creating a routable map. It appears
that the default style completely disregards the access tags access=no,
vehicle=no, motorvehicle=no and motorcar=no. Naturally I'd like to
exclude these from routing, but there seem to be no rules evaluating
them in the
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
Steve Ratcliffe wrote:
> Hi
>
> I am going to merge all the multipolygon fixes.
> Including, if appropriate, the sea polygon changes.
>
> In addition to the patches sent to the list I also
> have permission to use the attached patch from Olaf Kähler
> which he describes as follows:
>
>
>> I gues
Hello Nop,
> I am just having my first look at creating a routable map. It appears
> that the default style completely disregards the access tags access=no,
> vehicle=no, motorvehicle=no and motorcar=no. Naturally I'd like to
> exclude these from routing, but there seem to be no rules evaluati
>> private int roundDown(int val) {
>> return val >> SHIFT << SHIFT;
>> }
> I would write this as
>
> return val & ~(1 << SHIFT);
That's not the same thing though. I assume you really mean:
return val & ~((1 << SHIFT) - 1);
And in fact that's what was there originally for positive numbers. Nega
23 matches
Mail list logo
