On 24 Aug 2009, at 07:49, Brett Henderson wrote:
Dennie.nl wrote:
Brett, apologies for sending the email direct to you!
Hello Brett,
The ruby problems are solved, I mentioned them for future reference
(if somebody searches the archives). Next time I will run it on an
virtual appliance,
Hi Lars,
While it's not solving exactly the same problem as you, the mkgmap splitter
utility is faced with similar challenges. It is written in Java and uses
various techniques to reduce the amount of memory required while processing
the planet osm. I've spent quite a bit of time profiling and
Hi Ben,
BS This may be a little bit useless but...I use multi-pass and tiling
BS techniques to get the planet under my control for my work...I'm
BS using C but a 32-bit process, so these techniques should work with
BS Java.
Yep that's basically what the splitter does too. I'm still considering
The new Bad data proposal is a scheme to mark traced aerial photography or
maps as out of date or otherwise unreliable so that they can be obscured
in editors and users dont copy details into the OSM database reducing its
accuracy.
http://wiki.openstreetmap.org/wiki/Bad_data
2009/8/23 Stephan Knauss o...@stephans-server.de:
Hi,
is there any practical use for ways without nodes? There are over 600 of
such ways in the database, latest one changed 2009-04-16
I also recently noticed that as many as some 7000 out of the 180k
relations there are in the database
andrzej zaborowski wrote:
Unlikely but possible.
Very unlikely. What too should find that relation? Josm will not. For
which bounding box should the api return this empty relation?
So would need another relation with members.
The mentioned ways are not referred by any relation (except 7).
I
2009/8/25 Stephan Knauss o...@stephans-server.de:
andrzej zaborowski wrote:
Unlikely but possible.
Very unlikely. What too should find that relation? Josm will not. For which
bounding box should the api return this empty relation?
Right that's the problem with empty relations and the only
7 matches
Mail list logo
