I am relatively very new to building GIS based applications and have a very limited understanding in this area. So I need some help in building a java based desktop application which would generate map tiles on the fly for a given tile coordinates (zoom level, x and y coordinate of the tile). I could build a reasonable solution using the below procedure using PostgreSQL/PostGIS and GeoTools APIs. But now my client wants me to use the embedded database instead of PostgreSQL/PostGIS since that eliminates the database administration.

Here is what I have done so far:

  1. Downloaded osm data and used osm2pgsql tool to populated the required osm tables in PostgreSQL/PostGIS data.
  2. I have used mapnik's SLD files to style the map objects (openstreetmap.org serves the tiles generated by mapnik). I have used mapnik to generate the SQL script that populates the map objects tables in PostgreSQL/PostGIS database using osm tables in step 1 and the SLD files that can be used by geotools API to syle the objects. By map objects, I mean objects like roads, buildings, addresses etc which are map features that get loaded into each layer of the map.
  3. GeoTools has APIs (StreamingRenderer) to generate the raster image of the bounding box that corresponds to a given tile coordinate. The generated raster image gets served as the tile.

I have started exploring spatialite (spatial extension to sqlite) since I found that GeoTools has a plugin for spatialite which will load the map objects into the map. I am able to load the OSM data into spatialite tables using the spatialite-tool "spatialite_osm_map". Looking at the tables generated in spatialite, it seems like all map objects got populated. But I am not sure how to render these map objects of spatialite. I am not able to use the SLD files that were meant for postgis map objects. I would want to leverage the styling done for PostGIS, but that does not seem to be possible. I have googled quite a bit and did not find anyone using SLD files to style the spatialite map objects. Typically one uses desktop application such as QGIS to show the map objects of spatialite. The spatialite 4.1.0 has started supporting SLD styling, but that version is not compatible with GeoTools plugin for spatialite which relies on version 2.4.0.

So with all these constraints, I guess I need to adopt entirely different approach of using embedded database. May be some other embedded databases. I looked at this discussion in this site, but among all of them I found spatialite to be more popular and being actively used and hence started exploring it.

Has anyone used any other embedded database to solve this kind of problem?

Can someone guide me through this?

I guess one way could be storing the already generated tiles in sqlite (conforming to MBtiles spec) but that may not be acceptable by my client since he wants tiles to be generated on the fly.

I would like use a embedded database (for e.g. spatialite) in my java desktop application to store the map data (osm data) instead of PostGIS/PostgreSQL and be able to generate the tile on the fly for a given tile coordinate using the stored map data. The generated tile should look similar to what one sees in openstreetmap.org.

Any suggestions to achieve this workflow?

It seems QGIS does not out of the box support for java based on this discussion.

I did look at spatiliate link that you mentioned - The SLD styling is supported in spatialite 4.1.0 and the geotools-spatialite plugin which I am presently using is compatible with spatialite 2.4.0. However I can go ahead and use spatialite 4.1.0, but I did not find any java framework that can possibly help me in achieving the workflow of reading the map data and generate tiles similar to openstreetmap.

I will take dig at uDig and see if Neo4j spatial can be used in my case.

Regarding on-the-fly generation of tiles - My client does not want to store all the tiles for various zoom levels (required zoom level is around 20) in the database or file system since that would be a huge data to be stored and is impracticable for him.