Hi Chris,
new splitter works great. attached a small patch to make the kml tiles
transparent in Google Earth and add a simple balloon with the tile
name when you click it. GE behaves different than GMaps where this is
not needed. But patch will work in GMaps too.
If this is useful for
Hi Apo,
AS new splitter works great. attached a small patch to make the kml
AS tiles
AS transparent in Google Earth and add a simple balloon with the tile
AS name when you click it. GE behaves different than GMaps where this
Thanks, this is something I'd noticed and was meaning to take a look at
Chris, thanks for al the good work. Just a small and unrelated remark.
The script that builds my map first unpacks the osm.bz2 file, then runs
splitter. Still, Splitter complains about no --cache being used, while
as far as I understand, there's no real advantage using --cache if
you're using
Oh, this is so awesome Chris! Just awesome!!
Chris Miller wrote:
I've just checked in a new version of the splitter (r84) that requires far
less memory and also performs slightly better during the first stage of the
split. As an example, it used to take about a 5GB heap to generate
2009/9/3 Chris Miller chris.mil...@kbcfp.com:
I've just checked in a new version of the splitter (r84) that requires far
less memory and also performs slightly better during the first stage of the
split. As an example, it used to take about a 5GB heap to generate areas.list
for the whole
Really great,
what we would need now is a possibitlity to split by countries.
e.g. taking europe.osm.bz2 and splitting it into all major states, this
would avoid having to use the tiles from geofabrik which cannot be
merged without having broken routing at the frontiers.
Has anyone any idea
Hi Valentijn,
It depends... how many areas does your osm file get split into, and what
value (if any) are you using for --max-areas? Are you providing your own
areas.list file via the --split-file parameter?
It's still noticably slower to parse an osm file (even an uncompressed one)
than it
Hi Chris
Where to from here? As some of you may have guessed, this new splitter is
Here are a few ideas based on things that we discovered with earlier
versions of the splitter.
* Avoid pathalogical behaviour at the poles by limiting latitude to +- 85.
* Split tiles that are larger than a
Hi Steve,
SR Here are a few ideas based on things that we discovered with earlier
SR versions of the splitter.
Thanks for this, these points are all new to me.
SR * Avoid pathalogical behaviour at the poles by limiting latitude to
SR +- 85.
What should I do with nodes/ways/rels outside this
L And are (large) polygons that span many tiles fully supported?
The splitter has been able to handle relations that span an unlimited number
of tiles since r49, and ways that span many tiles since r60 or so. As far
as I'm aware the only remaining problem is that a node is still limited to
4
Ok, thanks for clearing this up for me. I don't actually know if there
is a real world problem with this, it's just that I was still thinking
that this was a limitation...
Chris Miller wrote:
L And are (large) polygons that span many tiles fully supported?
The splitter has been able to
On 03/09/09 14:49, Chris Miller wrote:
L And are (large) polygons that span many tiles fully supported?
The splitter has been able to handle relations that span an unlimited number
of tiles since r49, and ways that span many tiles since r60 or so. As far
I'm not sure if this what Lambertus
Very good point. I guess if someone came across such a situation a nasty
workaround would be to increase the --overlap value by enough to make the
problem go away, though that would likely introduce other problems (memory
usage, performance, nodes in 4 areas, ...).
A proper fix would require
13 matches
Mail list logo
