search

geopaparazzi / geopaparazzi

Because not all paparazzis are evil!
GNU General Public License v3.0
149 stars 75 forks source link

AbstractSpatialTable - Refactoring needed #281

Closed mj10777 closed 9 years ago

mj10777 commented 9 years ago

While attempting to adapt the needed logic to support RasterLite2-Styles support for

I see the need to refactor the code the process between

     * Return layerTypeDescription
     * <p/>
     * <p>[SpatialRasterTable] 'SpatialTable'
     * <p>[SpatialVectorTable] 'SpatialView'
     * <p>[SpatialRasterTable] 'MBTiles'    
     * <p>[MapTable] (Mapsforge) 'Map'   
     * <p>[CustomTileTable] 'Mapurl'       
     * TODO: ? add to 'TableTypes':
     * - added as GPKGRASTER/GPKGVECTOR
     * <p>[SpatialRasterTable] 'GeoPackage_tiles'
     * <p>[SpatialVectorTable] 'GeoPackage_features'

these are created in:

5 functions that need to be adapted when adding anything new

Goals:

The process would then be:

Inside the DatabaseHandler

SpatialVectorTable table = new SpatialVectorTable(getDatabasePath(),vector_key,vector_value)
if (table.IsValid())
 vectorTableList.add(table);

Not all classes use GeneralQueriesPreparer to create

String layerType = SpatialDataType.MBTILES.getTypeName();
String vector_key=databaseFileNameNoExtension+";0:"+layerType+";"+databaseFileNameNoExtension+";"+tableName+";default";
String s_bounds=this.boundsWest + "," + this.boundsSouth + "," + this.boundsEast + "," + this.boundsNorth+ "," + this.centerX+ "," + this.centerY;
String vector_value=this.minZoom+";"+this.maxZoom+";4326;"+defaultZoom+";0;"+s_bounds+";?,?,?";
SpatialRasterTable table = new SpatialRasterTable(databasePath, vector_key,vector_value)
if (table.IsValid())
 rasterTableList.add(table);

One major problem with the DatabaseHandler was

In all cases, the bounds - if not in WSG84 must be transformed

However for SpatialVectorTable

Since, at the moment, AbstractSpatialTable

Since a major Goal is to simplify the maintenance in one place

So a policy decision is needed here

I would prefer the first option

At present I built in logic to store the first found Spatialite-Database in

Missing is still the logic

The intention was for this to be used for

but because of the above problem (collectTableFields)

So a policy decision is needed here

The result of this will be submitted to the

The first commit to this branch is based on the present code

The (indended) second commit to this branch

Timeframe:

mj10777 commented 9 years ago

The major coded change have now been made.

Work still needed to be done to insure that

The usage of vector_key and vector_value

The changes have been committed to rasterlite2_styles branch

mj10777 commented 9 years ago

The rasterlite2_styles branch

AbstractSpatialTable

SpatialRasterTable

SpatialiteDatabaseHandler

SpatialiteUtilities

TableTypes

SPL_Geopackage

SPL_Vectors

SPL_Vectors New Functions:

SPL_Rasterlite

LibraryConstants

General changes

mj10777 commented 9 years ago

A sample showing

rl2_calculate_zoom_levels[chm_geotiff] srid[32632] 
d_width_min[2985.1916391210398] d_width_max[377.9352318990277] 
zoom_min[15] zoom_max[19] zoom_default[17]  
s_sql_command[
SELECT 
(
 SELECT 
  (((ST_MaxX(ST_Transform(geometry,3395))-
     ST_MinX(ST_Transform(geometry,3395)))/512)*256) 
  FROM 'chm_geotiff_tiles' 
  ORDER BY pyramid_level ASC LIMIT 1
) AS zoom_max,
(
 SELECT 
  (((ST_MaxX(ST_Transform(geometry,3395))-
     ST_MinX(ST_Transform(geometry,3395)))/512)*256) 
  FROM 'chm_geotiff_tiles' 
 ORDER BY pyramid_level DESC LIMIT 1
) AS zoom_min;
]
rl2_calculate_zoom_levels[1868.rote_rathausturm_panorama] srid[187999] 
d_width_min[8181.442336302018] d_width_max[421.2816632759059] 
zoom_min[14] zoom_max[20] zoom_default[17]  
s_sql_command[
SELECT 
(
 SELECT 
 (((ST_MaxX(ST_Transform(SetSRID(geometry,187999),3395))-
    ST_MinX(ST_Transform(SetSRID(geometry,187999),3395)))/512)*256) 
 FROM 
  '1868.rote_rathausturm_panorama_tiles' 
 ORDER BY pyramid_level ASC LIMIT 1
) AS zoom_max,
(
 SELECT 
  (((ST_MaxX(ST_Transform(SetSRID(geometry,187999),3395))-
     ST_MinX(ST_Transform(SetSRID(geometry,187999),3395)))/512)*256) 
 FROM 
  '1868.rote_rathausturm_panorama_tiles' 
 ORDER BY pyramid_level DESC LIMIT 1
) AS zoom_min;
]

20150722 rl2_styles

moovida commented 9 years ago

Great great stuff @mj10777 . My return from the Foss4g Europe has been quite cray and I have piles of work to finish. As soon as I have time, I will go through all your comments (only could quickly read through them) and give feedback. Thanks

mj10777 commented 9 years ago

In the mean time, further code refactoring has been attempted

Whereby:

Based on the following criteria:

But also:

where one can assume other Applications would find useful

For this, a library directory has been added.

The committed changes in branch rasterlite2_styles

All references inside geopaparazzi.app and geopaparazzimapsforge

For those Classes not used inside geopaparazzilibrary

For those Classes used inside geopaparazzilibrary

dependencies {
     // compile project(":geopaparazzilibrary")
         compile files('libs/httpmime-4.2.2.jar')
         compile files('libs/android-support-v4.jar')
}

And all resulting resources copied into eu.geopaparazzi.spatialite

The next stage, which I will try to complete today, will bee to add the dependency

mj10777 commented 9 years ago

--part 2 -- While working on building in the dependency of

(while changing GPLog and GPApplication)

this part will contain a list of directories, where the classes inside do not have further dependencies

this part will contain a list of directories, where the classes inside do have have further dependencies

moovida commented 9 years ago

Hi @mj10777 , I am quite worried about this proposal of yours. It is true that Geopaparazzi also wants to act as a library to create location based apps, but it is meant for survey-type apps that base on the geopaparazzi database model, not any gps or spatialite based app. That is the reason some stuff (that you decided to move/copy into spatialite library) has been put into the library project.

I have been able to only browser for about half an hour your changes, but I can state that this proposal will never make it into the master branch. First because it is not the way I designed Geopaprazzi to work. I don't see why gpx and network and other packages should be moved (or even worse duplicated) into the spatialite project. Even the LibraryConstants has been copied and now has a new epsg added, which is really really app specific: SRID_BRANDENBURGER_TOR_187999

Some comments:

mj10777 commented 9 years ago

After saving the above to a branch spatialite_handler

Should I upload the spatialite_handler branch (where the duplicated have been removed, that what I was working on today)

SRID_BRANDENBURGER_TOR_187999

moovida commented 9 years ago

Closing this, discussion has been going on in the pull request