logo separator

[mkgmap-dev] creating precompiled boundaries with Derby DB?

From WanMil wmgcnfg at web.de on Mon Feb 20 19:46:56 GMT 2012

Hi Gerd,

I don't veto against that but I don't see the big reason for that. 
Preparing boundaries must not be performed by anyone because they are 
downloadable on some sites. If you really like to create your own 
boundaries you can split the planet file into smaller pieces and merge 
them afterwards.
So in the end you have quite a lot of development work but not a big 
improvement. I think there are more important things to be reworked.

But that's just my singular opinion.

WanMil

> Hi,
>
> would it be okay to change the BoundaryPreparer so that it (optionally)
> stores data in a Derby DB instead of keeping everything on the heap?
> http:////http://www.oracle.com/technetwork/java/javadb/overview/index.html
> Java DB
>
> Due to the growth of the OSM data I can no longer create europe *.bnd files
> with -Xmx2800m (which seems to be the max. value on my machine)
> I think the current process of extracting boundary data with osmconvert and
> osmfilter is already quite complex, and maybe a simple DB will help.
> The idea: The BoundaryElementSaver could store the data in a DB(maybe only
> the coord data).
> This would allow to create the *.bnd files with less than 1GB of memory.
>
> Any objections against this?
>
> Gerd
>
>
>
> --
> View this message in context: http://gis.19327.n5.nabble.com/creating-precompiled-boundaries-with-Derby-DB-tp5498179p5498179.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>




More information about the mkgmap-dev mailing list