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
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
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
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
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
> 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
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
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
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
> How does a node get to be in more than four areas?
>
> ..Steve
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
Hi
> One thing I noted during the testing of this fix is that setting
> max-nodes=30
> for europe.osm triggers a lot of "Node in too many areas" warnings, due to
> a fair number of nodes ending up in 5+ areas. I can partially or even
> completely
> fix this as long as the number of nodes s
OK I've isolated the secondary problem and checked in a fix. Subtle bug,
I was using a 1 (int) instead of a 1L (long) during some bitshifting and
was suffering from overflow in certain situations. Sorry for any trouble
this bug may have caused, hopefully it's all working now as I'd originally
i
2009/8/9 Chris Miller :
> Hmm, running with max-nodes=30 on r65 now makes it further, but fails
> with another (related) problem. I'm going to try and find the problematic
> way(s)/relation(s) so I can make a test case. Please hold off on big splits
> with r65 for now.
>
Thanks! I am waiting f
Hmm, running with max-nodes=30 on r65 now makes it further, but fails
with another (related) problem. I'm going to try and find the problematic
way(s)/relation(s) so I can make a test case. Please hold off on big splits
with r65 for now.
> Have a try with splitter r65, I've just checked in
Have a try with splitter r65, I've just checked in a fix that should solve
your problem. I reran it against today's europe.osm and it completed
successfully:
..
12,000,000 ways processed...
Writing relations Sun Aug 09 14:19:27 BST 2009
50,000 relations processed...
100,000 relations processed..
> I still wonder if the problem is with Geofabrik, and not with
> splitter?
I haven't started digging into this bug yet but superficially at least it
does appear to be a problem with some of the new code in the splitter. Possibly
the problem is triggered by malformed XML, but more likely I think
Hi Paul,
Thanks for the detailed bug report, and sorry for the inconvenience this
one has caused you. It looks like there's a bug in the new code for handling
ways that span > 4 areas. I'll take a look shortly and hopefully have a fix
later today.
As an aside, I see you have set --max-areas=10
On Aug 9, 2009, at 11:24, Paul Ortyl wrote:
> I have just testet the latest svn version of splitter (r64)
> I get the following exception:
>
> 12,000,000 ways processed...
> [GC 926169K->330369K(1422720K), 0.0038790 secs]
> Writing relations Sun Aug 09 11:11:14 CEST 2009
> [GC 837769K->592513K(142
Hello!
I have just testet the latest svn version of splitter (r64)
I get the following exception:
12,000,000 ways processed...
[GC 926169K->330369K(1422720K), 0.0038790 secs]
Writing relations Sun Aug 09 11:11:14 CEST 2009
[GC 837769K->592513K(1423296K), 0.1517410 secs]
Exception in thread "main"
19 matches
Mail list logo
