[gdal-dev] Enquiry
Dear Sir/Madam, I'm a student in HSR, Rapperswil and I am trying to clip a SQLite file I converted .osm.pbf file of liechtenstein to a .sqlite file, and then tried to clip it with the following codes, (is it -clipsrc or -clipdst ogr2ogr -f SQLite liechtenstein.sqlite liechtenstein-latest.osm.pbg -skipfailures -dsco SPATIALITE=yes -clipsrc 47.1386361 9.5231616 47.1404971 9.5266377 Also, I tried to clip the map of Singapore but was unsuccessful, the following is the code ogr2ogr -f SQLite singapore.sqlite malaysia-singapore-brunei-latest.osm.pbg -skipfailures -dsco -clipsrc singapore.geojson Do I have to convert to .shp file? Do you have any suggestions? Thank you! Hao Feng. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Enquiry
Hao, The extents for -clipsrc have to be represented in the source's reference system. You can use gdaltransform [1] if you want to convert your lat/long to the source's ref system. [1]: http://www.gdal.org/gdaltransform.html On Wed, Mar 19, 2014 at 1:16 PM, Tan Hao Feng h...@hsr.ch wrote: Dear Sir/Madam, I'm a student in HSR, Rapperswil and I am trying to clip a SQLite file I converted .osm.pbf file of liechtenstein to a .sqlite file, and then tried to clip it with the following codes, (is it -clipsrc or -clipdst ogr2ogr -f SQLite liechtenstein.sqlite liechtenstein-latest.osm.pbg -skipfailures -dsco SPATIALITE=yes -clipsrc 47.1386361 9.5231616 47.1404971 9.5266377 Also, I tried to clip the map of Singapore but was unsuccessful, the following is the code ogr2ogr -f SQLite singapore.sqlite malaysia-singapore-brunei-latest.osm.pbg -skipfailures -dsco -clipsrc singapore.geojson Do I have to convert to .shp file? Do you have any suggestions? Thank you! Hao Feng. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Enquiry
Tan Hao Feng htan at hsr.ch writes: Dear Sir/Madam, I'm a student in HSR, Rapperswil and I am trying to clip a SQLite file I converted .osm.pbf file of liechtenstein to a .sqlite file, and then tried to clip it with the following codes, (is it -clipsrc or -clipdstogr2ogr -f SQLite liechtenstein.sqlite liechtenstein-latest.osm.pbg -skipfailures -dsco SPATIALITE=yes -clipsrc 47.1386361 9.5231616 47.1404971 9.5266377 Also, I tried to clip the map of Singapore but was unsuccessful, the following is the code ogr2ogr -f SQLite singapore.sqlite malaysia-singapore-brunei-latest.osm.pbg -skipfailures -dsco -clipsrc singapore.geojson Do I have to convert to .shp file? Do you have any suggestions? Thank you! Hao Feng. Hi, I suggest to check the names of your input files. Are you sure they are .pbg and not .pbf? Clipsrc takes coordinates in the source projection, clipdst in target projection. Both mean the same if you do not use different -s_srs and -t_srs parameters. Did you not find the information from manual page http://gdal.org/ogr2ogr.html? Read also the manual page of SQLite/Spatialite format. I bet that you will want to create Spatialite database and not a regular FDO database. Here is a fast running query that worked for me: ogr2ogr -f SQLite -dsco spatialite=yes clip.sqlite finland-latest.pbf -gt 2 -progress --config OGR_SQLITE_SYNCHRONOUS OFF --config OSM_COMPRESS_NODES YES -clipsrc 27 65 28 66 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Change SQLite default to -spatialite=yes?
Hi, Would it hurt bad if the SQLite/Spatialite driver would use -co spatialite=yes as a default? Is there anybody really using the regular FDO type SQLite databases? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Enquiry
Hi, It may not be a good idea to use -clipsrc with OpenStreetMap data at least without some thinking. Clipping is cutting linestrings like highways which intersect the clipping geometry into pieces and that is changing the geometry type of clipped highway from linestring into multilinestring. Such a highway cannot be stored into Spatialite table lines where it normally belongs because of geometry type constraint. You can add -nlt PROMOTE_TO_MULTI parameter into ogr2ogr but then all the highways will be converted into multilinestrings. It may be OK for you to do so, but think about that first. Alternative way for clipping OSM data would be to use special tools like Osmosis. I believe is has an option that selects the intersecting features without cutting them into pieces. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Vincent Mora
Le vendredi 14 mars 2014 16:42:29, Even Rouault a écrit : Motion: Extend GDAL/OGR commit access to Vincent Mora. I declare this motion passed with support from PSC members FrankW, JukkaR, TamasS, HowardB, DanielM and me. Welcome aboard Vincent ! Vincent, I've added you to the committer list. To check that it works, could you add yourself to the COMMITERS file ? Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GML / NAS code redundancy
Le mardi 18 mars 2014 23:04:56, Jukka Rahkonen a écrit : Even Rouault even.rouault at mines-paris.org writes: Selon Martin Landa landa.martin at gmail.com: Hi, 2014-03-18 17:50 GMT+01:00 Even Rouault even.rouault at mines- paris.org: I haven't looket at the file but from the above, the logic of the application schema registry would need to be extended since it currently only supports one feature type per file. You would need to ingest the full file to recognize which feature types are in it. there is probably some misunderstanding, at [1] there is mentioned Finish registry which contains different feature types (KiinteistorajanSijaintitiedot, PalstanTunnuspisteenSijaintitiedot, ...). It means that in the input file can be only one feature type not all of them? Yes, as far as I remember there were only one feature type per file, hence this (non-fundamental) restriction in the code. I looked at bit at your sample and I think you could just use the current code without changing it (well perhaps increase the szHeader size). Add in the GML registry your feature types and make them point to the same .gfs file that define all the feature types ! The only drawback is that you could have empty layers if not all feature types are found, but that should work OK otherwise. Hi, If you want to compare the data from National Land Survey of Finland you can find the schema for each feature type from page http://www.maanmittauslaitos.fi/aineistot-palvelut/rajapintapalvelut/kiinte istotietojen-kyselypalvelu-wfs/kayttoonotto/aineistot-tuo Follow links Tuotteen skeema. Data samples are available from page http://www.maanmittauslaitos.fi/aineistot-palvelut/rajapintapalvelut/kiinte istotietojen-kyselypalvelu-wfs/kayttoonotto/kyselyt-esime follow links GML-vastaussanoma. Each featuretype is separate but may contain many layers C:\data\MML-GMLogrinfo palstan_tietoja.gml Had to open data source read-only. INFO: Open of `palstan_tietoja.gml' using driver `GML' successful. 1: RekisteriyksikonTietoja (None) 2: RekisteriyksikonPalstanTietoja (Unknown (any), Unknown (any)) 3: KiinteistorajanTietoja 4: RajamerkinTietoja Just for Martin's enlightment, the GML driver manages to recognize several layers in that case since the RekisteriyksikonTietoja is the top feature present in the first bytes of the file, and the other feature types are sub feature types, also defined in RekisteriyksikonTietoja.xsd. In the case, the schema were simple enough so that the XSD parser could understand them. For Martin's case, I think that a .gfs will be necessary to extract properties in nested XML elements. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Change SQLite default to -spatialite=yes?
Le mercredi 19 mars 2014 09:13:29, Jukka Rahkonen a écrit : Hi, Would it hurt bad if the SQLite/Spatialite driver would use -co spatialite=yes as a default? Yes, I guess that would make sense (when spatialite is available). Another option would be to have a spatialite driver, that would just extend the sqlite driver (no real new code), but with a more meaningful name. So : ogr2ogr -f spatialite out.db in.shp would, more or less, internally translate to ogr2ogr -f sqlite out.db in.shp -dsco spatialite=yes The only drawback would be when opening: both the regular (FDO) sqlite driver and spatialite driver would have to open and query a bit the DB to figure out if it is the kind of SQLite DB they handle. But that shouldn't count for more than a few dozains of milliseconds for local files. Is there anybody really using the regular FDO type SQLite databases? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Change SQLite default to -spatialite=yes?
Hi Jukka, To: gdal-dev@lists.osgeo.org From: jukka.rahko...@mmmtike.fi Date: Wed, 19 Mar 2014 08:13:29 + Subject: [gdal-dev] Change SQLite default to -spatialite=yes? Hi, Would it hurt bad if the SQLite/Spatialite driver would use -co spatialite=yes as a default? Is there anybody really using the regular FDO type SQLite databases? I don't know how the FDO uses that driver but I once was asked to try to setup and try the Berkeley DB with that OGR driver. Everything works just fine at that moment and I never checked that again. A default like you propose might be OK. The problem is if the driver becomes dependent on one or another storage, so next time a user updates GDAL their option doesn't work anymore. For us, developer, it's hard to keep track without autotests that include Berkeley DB (and FDO, I guess). Regards, Ivan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp _ RPC_DEM ignored ?
The link Alain is referring to is Frank's Blog [http://fwarmerdam.blogspot.com/]. I just realized that I reply only to Alain, not to the gdal-dev. Alain, we can see from your gdalinfo report that don't have RPC's on that file and even the GCP's that you have doesn't have height, so it's impossible to do ortho rectification and use the RPD_DEM parameter appropriately. Date: Wed, 19 Mar 2014 09:18:10 +0100 From: alain.sau...@univ-paris1.fr To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdalwarp _ RPC_DEM ignored ? Hi, thank you for your answer. I probably misunderstood the relation between RPC and GPC. Ivan, thank you for the link, Dimitriy, I did not define any coefficient (i did'nt know that i have to...). I used to orthorectify my photo with Erdas Imagine, wich was, in a way, more easier : only define GPC, link a DEM and it was almost done... Below is the output of gdalinfo, regards Alain asauter@Z800:~$ gdalinfo /tmp/photo101.tif Driver: GTiff/GeoTIFF Files: /tmp/photo101.tif Size is 12076, 11206 Coordinate System is `' GCP Projection = GCP[ 0]: Id=1, Info= (10346.2,10558.6) - (996517,6690260,0) GCP[ 1]: Id=2, Info= (10688.7,7989.49) - (996604,6691840,0) // some more GCP's here // GCP[ 30]: Id=31, Info= (3018.4,6207.98) - (991844,6692570,0) GCP[ 31]: Id=32, Info= (9443.26,10907.6) - (6659940,6690,0) GCP[ 32]: Id=33, Info= (8409.41,7437.51) - (995221,6692050,0) Metadata: TIFFTAG_DOCUMENTNAME=/Documents/photo101.tif TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) TIFFTAG_XRESOLUTION=72 TIFFTAG_YRESOLUTION=72 Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0,11206.0) Upper Right (12076.0,0.0) Lower Right (12076.0,11206.0) Center ( 6038.0, 5603.0) Band 1 Block=12076x1 Type=Byte, ColorInterp=Gray On 18/03/2014 22:25, Dmitriy Baryshnikov wrote: Hi, the parameter may ignored because the input tiff lack the RPC coefficients. Does any of RPC coefficient exist? What is gdalinfo output of you aerial photos? Best regards, Dmitry 18.03.2014 23:54, alain Sauter пишет: Hi all, I am trying to orthorectify a couple of aerial photos using gdalwarp, but i am stuck with the -to transformer option. I have seen in archive two request concerning this issue, but without any answer for now... so hope this 3rd will have a reply ;) materials : scan of an old aerial photo, without fly info and, of course, without projection, tif format Dem of the region, tif format what i've done : using qgis georeferencer to grab some GPC's on the aerial photo using gdal_translate to insert GPC's in the aerial photo what i've try : using gdalwarp to transform, rectify and project the aerial photo with : gdalwarp -to RPC_DEM=dem.tif -t_srs=EPSG:2154 input.tif output.tif result: my file is transformed and projected but not rectified. Option -to RPC_DEM is ignored by gdalwarp, even if I write wrong option like -to RP_D... Am i doing something wrong ? thanks for reply Alain ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Change SQLite default to -spatialite=yes?
Le mercredi 19 mars 2014 15:03:20, Ivan Lucena a écrit : Hi Jukka, To: gdal-dev@lists.osgeo.org From: jukka.rahko...@mmmtike.fi Date: Wed, 19 Mar 2014 08:13:29 + Subject: [gdal-dev] Change SQLite default to -spatialite=yes? Hi, Would it hurt bad if the SQLite/Spatialite driver would use -co spatialite=yes as a default? Is there anybody really using the regular FDO type SQLite databases? I don't know how the FDO uses that driver but I once was asked to try to setup and try the Berkeley DB with that OGR driver. Everything works just fine at that moment and I never checked that again. A default like you propose might be OK. The problem is if the driver becomes dependent on one or another storage, so next time a user updates GDAL their option doesn't work anymore. For us, developer, it's hard to keep track without autotests that include Berkeley DB (and FDO, I guess). Ivan, I'm not sure what Jukka's proposal has to do with using regular sqlite backend or Berkeley DB. I thought the impact was only to linking to Berkely DB, no ? Spatialite has little to do with that : it is just a SQLite extension (I don't know Berkeley DB, but perhaps you could have spatialite working with Berkeley DB, but that would imply that Berkely DB offers the same extension API than SQLite3, which is not obvious), and if your GDAL build doesn't link against spatialite, then this would steal produce FDO-style SQLITE DB. Both FDO-style and Spatialite-style DBs are tested in autotests. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Fwd: [OSGeo-Discuss] Any one is interested in the support of GDAL for MongoDB?
Fowarding to gdal-dev where this might raise more interest. -- Message transmis -- Sujet : [OSGeo-Discuss] Any one is interested in the support of GDAL for MongoDB? Date : mercredi 19 mars 2014, 15:25:46 De : Zhang, Shuai sh...@illinois.edu À : OSGeo Google Summer of Code list s...@lists.osgeo.org, OSGeo Discuss list disc...@lists.osgeo.org, OSGeo Education List edu_disc...@lists.osgeo.org, ICA OSGeo Labs list ica-osgeo-l...@lists.osgeo.org Hi All, Sorry to bother, but i think we need a mentor for the idea to have GDAL support MongoDB. http://trac.osgeo.org/gdal/wiki/SummerOfCode I noticed that GDAL has a CouchDB driver which is a good start to have GDAL powered by NoSQL Database Technologies. However, I think GDAL community should pay attention to MongoDB as well. MongoDB, which has native support for maintaining geospatial data, using a document-oriented model, lies in fifth place in the DB-Engines Ranking (http://db-engines.com/en/ranking) of database management systems classed according to popularity and the highest rated non-relational system. From version 2.4 (released on March 19, 2013), MongoDB introduces Geohash indexes support for a subset of GeoJSON geometries including basic shapes like points, linestrings, polygons. And quite a number of partners related with big data, NoSQL, cloud, mobile and high performance computing join the MongoDB ecosystem. I spent several years developing parallel geo-algorithms to tackle some geo- problems on the high performance computing platform, and had a burning feelings that we need a powerful and distributed spatial database to cooperate with the hpc environment running on the large scale Linux cluster. Unfortunately we don't have much choices in the GIS fields. MongoDB and CouchDB may be a good ground to start with. Perhaps, we should make GDAL spinning on MongoDB platform simply because it will prevent us from re-invent the wheel and get lots of GIS tools reusable to deal with the geo-info maintain in the NoSQL database, and enable the Open Source GIS Ecosystem powered by the advanced NoSQL database since GDAL servers as the foundation. Thanks, shuai --- -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] JP2/J2K codecs in JP2OpenJPEG dataset
Hi list,
looking at the JP2OpenJPEG format handler (./frmts/openjpegdataset.cpp), it
seems that only the codec JP2 (and not J2K) is accepted in order to enable
extra boxes (eg GMLJP2 or GeoJP2 ones).
Might be wrong, but aren't JP2/J2K equivalent formats?
---if( eCodecFormat == OPJ_CODEC_JP2
+++if( (eCodecFormat == OPJ_CODEC_JP2 || eCodecFormat == OPJ_CODEC_J2K)
(CSLFetchBoolean( papszOptions, GMLJP2, TRUE ) ||
CSLFetchBoolean( papszOptions, GeoJP2, TRUE )) )
{
I couldn't find much information about the difference between the two
codecs, but in case I am missing something just forget all this.
cheers,
Piero
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JP2/J2K codecs in JP2OpenJPEG dataset
Le mercredi 19 mars 2014 18:16:57, Piero Campalani a écrit :
Hi list,
looking at the JP2OpenJPEG format handler (./frmts/openjpegdataset.cpp), it
seems that only the codec JP2 (and not J2K) is accepted in order to enable
extra boxes (eg GMLJP2 or GeoJP2 ones).
Might be wrong, but aren't JP2/J2K equivalent formats?
No, JP2 is J2K plus boxes to add metadata. See File format and code stream
paragraph of http://en.wikipedia.org/wiki/JPEG_2000
---if( eCodecFormat == OPJ_CODEC_JP2
+++if( (eCodecFormat == OPJ_CODEC_JP2 || eCodecFormat == OPJ_CODEC_J2K)
(CSLFetchBoolean( papszOptions, GMLJP2, TRUE ) ||
CSLFetchBoolean( papszOptions, GeoJP2, TRUE )) )
{
I couldn't find much information about the difference between the two
codecs, but in case I am missing something just forget all this.
cheers,
Piero
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hi, I think 7-8 days will be enough. According to you plan this issue will raise on 4-5 week then you'll export BRISK algorithm to GDAL. By now I don't see any problems - don't worry. Best regards, Dmitry 17.03.2014 22:05, Kshitij Kansal пишет: Hello Everyone I have submitted my proposal at the melange website. My proposal is available here https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/kansal/5629499534213120. Please review my proposal and give me some suggestions to make this proposal even more useful to the organization. @Dmitriy Chaitanya - I urge you to please specifically look into the common interface to various algorithms using some existing API part apart from the whole proposal, in my timeline. I have devoted 7-8 days for this work. If you people have some comments regarding this, kindly convey it to me. Thanking You all With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: [OSGeo-Discuss] Any one is interested in the support of GDAL for MongoDB?
Hi Even, I plan to mentor Geography Network support, but I can co-mentor one of such interesting projects: - OGR Driver for MongoDB - Bring up to speed the OGR style support for GDAL - Implement write support for the PostGIS Raster GDAL driver Best regards, Dmitry 19.03.2014 19:02, Even Rouault пишет: Fowarding to gdal-dev where this might raise more interest. -- Message transmis -- Sujet : [OSGeo-Discuss] Any one is interested in the support of GDAL for MongoDB? Date : mercredi 19 mars 2014, 15:25:46 De : Zhang, Shuai sh...@illinois.edu À : OSGeo Google Summer of Code list s...@lists.osgeo.org, OSGeo Discuss list disc...@lists.osgeo.org, OSGeo Education List edu_disc...@lists.osgeo.org, ICA OSGeo Labs list ica-osgeo-l...@lists.osgeo.org Hi All, Sorry to bother, but i think we need a mentor for the idea to have GDAL support MongoDB. http://trac.osgeo.org/gdal/wiki/SummerOfCode I noticed that GDAL has a CouchDB driver which is a good start to have GDAL powered by NoSQL Database Technologies. However, I think GDAL community should pay attention to MongoDB as well. MongoDB, which has native support for maintaining geospatial data, using a document-oriented model, lies in fifth place in the DB-Engines Ranking (http://db-engines.com/en/ranking) of database management systems classed according to popularity and the highest rated non-relational system. From version 2.4 (released on March 19, 2013), MongoDB introduces Geohash indexes support for a subset of GeoJSON geometries including basic shapes like points, linestrings, polygons. And quite a number of partners related with big data, NoSQL, cloud, mobile and high performance computing join the MongoDB ecosystem. I spent several years developing parallel geo-algorithms to tackle some geo- problems on the high performance computing platform, and had a burning feelings that we need a powerful and distributed spatial database to cooperate with the hpc environment running on the large scale Linux cluster. Unfortunately we don't have much choices in the GIS fields. MongoDB and CouchDB may be a good ground to start with. Perhaps, we should make GDAL spinning on MongoDB platform simply because it will prevent us from re-invent the wheel and get lots of GIS tools reusable to deal with the geo-info maintain in the NoSQL database, and enable the Open Source GIS Ecosystem powered by the advanced NoSQL database since GDAL servers as the foundation. Thanks, shuai --- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hello Dmitry Thank you. Is there anything else you can suggest regarding the proposal or Should I consider the current draft as the final one? I have planned it to the best way I could think of. I have tried to give enough time for testing, documentation and code cleaning also as it is a completely new implementation. If anything else comes up, please do let me know. Thanks for the support and ideas. With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Thu, Mar 20, 2014 at 1:34 AM, Dmitriy Baryshnikov bishop@gmail.comwrote: Hi, I think 7-8 days will be enough. According to you plan this issue will raise on 4-5 week then you'll export BRISK algorithm to GDAL. By now I don't see any problems - don't worry. Best regards, Dmitry 17.03.2014 22:05, Kshitij Kansal пишет: Hello Everyone I have submitted my proposal at the melange website. My proposal is available herehttps://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/kansal/5629499534213120 . Please review my proposal and give me some suggestions to make this proposal even more useful to the organization. @Dmitriy Chaitanya - I urge you to please specifically look into the common interface to various algorithms using some existing API part apart from the whole proposal, in my timeline. I have devoted 7-8 days for this work. If you people have some comments regarding this, kindly convey it to me. Thanking You all With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GSoC proposal looking for mentors and suggestions
Hi All, I think i need a mentor working with me and help me make gdal under mongodb support. Below is the proposal i wrote, hopefully you find it worth a trial. Thanks, shuai Title: OGR Driver for MongoDB Short description: MongoDB, a document database that provides high performance, high availability, and easy scalability, can be a good platform for storing extremely large spatial datasets, to support high performance geo-computation and real-time spatial analysis in a large scale.This project aims at developing a OGR Driver for MongoDB to help applications or softwares based on GDAL, such QGIS, Geoserver, Mapserver, and so on, read write the spatial data in it, and thus enable the Open Source GIS Ecosystem powered by the advanced NoSQL database. Describe your idea 1. Introduction MongoDB, a document database that provides high performance, high availability, and easy scalability, can be a good platform for storing extremely large spatial datasets, to support high performance geo-computation and real-time spatial analysis in a large scale. Yet, there is little attention so far that GIS fields pay to make most of its strength. This project aims at developing a OGR Driver for MongoDB to help applications or softwares based on GDAL read write the spatial data in it, and thus enable the Open Source GIS Ecosystem powered by the advanced NoSQL database. 2. Background Since we are living in the era of big data, tools and equipment today for capturing spatial data both at the mega-scale and the milli-scale are just dreadful. The magnitude of this data volume is well beyond the capability of any mainstream geographic information systems. Yet, we, GIS fields, have no off-the-shelf solutions to manage these massive spatial data. Relational spatial databases have taken in charge for decades but now the situation seems a little different. A computing pattern shift can be seen throughout the IT industry in recent years and GIS would be no exception. Especially, data analytics may not be achievable within a reasonable amount of time without resorting to high-performance computing strategies. However, relational spatial databases are kind of slow to support these high-performance computing scenarios, and often lack of flexible scalability to handle a growing amount of work in a capable manner. Fortunately, there are several groups trying to address the problem, and MongoDB is an apparent leader in this direction. MongoDB, which has native support for maintaining geospatial data, using a document-oriented model, lies in fifth place in the DB-Engines Ranking of database management systems classed according to popularity and the highest rated non-relational system. From version 2.4 (released on March 19, 2013), MongoDB introduces support for a subset of GeoJSON geometries including basic shapes like points, linestrings, polygons. And quite a number of partners related with big data, NoSQL, cloud, mobile and high performance computing join the MongoDB ecosystem. Foursquare is featured one of them which benefits from MongoDB’s support for geospatial indexing, allowing it to easily query for large location-based data. 3. The idea MongoDB employs GeoJSON to store spatial data and concurrently GDAL supports for access to features encoded in GeoJSON format, which can be reusable. This project is trying to implement a MongoDB Driver according to the OGR format driver interfaces with subclasses of OGRSFDriver, OGRDataSource and OGRLayer, and registered with the OGRSFDriverRegistrar at runtime, so that GDAL may use MongoDB as a datasource to access large scale spatial data. 4. Project plan (detailed timeline: how do you plan to spend your summer?) The first thing in the list is to design the structure inside of MongoDB spatial database. In the context of OGR data model, we got Datasource, Layer and Feature, so accordingly every database in MongoDB is regarded as a Datasource, and the Collections within should be treated as Layers, thus every Document as a Feature. PostGIS and other spatial databases often harness some system tables to maintain the metadata, but since MongoDB is schema free metadata such as spatial reference can be stored within the particular Layer, in this case a Collection. The most important part of a data format driver is to define how to read and write the data format in the specific driver, especially the Open and Create method in the Datasource Class. As MongoDB organizes its spatial data in GeoJSON model, the GeoJSON driver already supported by current GDAL can be reused to code or decode the GeoJSON fetched from MongoDB database. Therefore, there would be totally four files to implement, including ogr_mongo.h, ogrmongodriver.cpp, ogrmongodatasource.cpp, and ogrmongolayer.cpp. Test Plan [1] After the MongoDB Driver is compiled into the OGR framework, the utility ogr2ogr can be used as the test program to import and output spatial data
