Re: [gdal-dev] New OGR driver for DB2 Spatial support

Le vendredi 30 octobre 2015 15:01:39, David Adler a écrit : > The development and testing of this is complete as far as I am aware. > > Should the "svn diff" just be zipped and attached to a post to this group? David, I'd advise creating a Trac ticket with it as an attachemnt : https://trac.osg

Re: [gdal-dev] New OGR driver for DB2 Spatial support

The development and testing of this is complete as far as I am aware. Should the "svn diff" just be zipped and attached to a post to this group? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Re: [gdal-dev] New OGR driver for DB2 Spatial support

Le lundi 26 octobre 2015 22:35:48, David Adler a écrit : > I'm getting closer after installing the MS compiler for Python and > running "python setup.py build" successfully but still get a failure. > > Does the usual GDAL Python user need to go through all this? I see lots > of information and tut

Re: [gdal-dev] New OGR driver for DB2 Spatial support

I'm getting closer after installing the MS compiler for Python and running "python setup.py build" successfully but still get a failure. Does the usual GDAL Python user need to go through all this? I see lots of information and tutorials about using the GDAL Python API but haven't found much a

Re: [gdal-dev] New OGR driver for DB2 Spatial support

Le lundi 26 octobre 2015 20:32:12, David Adler a écrit : > Thank you for the quick response. > > I've not used Python before so I'm stumbling getting the environment to > work. Python 2.7 is installed and I am running from the autotest > directory. It isn't obvious to me how the PYTHONPATH variabl

Re: [gdal-dev] New OGR driver for DB2 Spatial support

Thank you for the quick response. I've not used Python before so I'm stumbling getting the environment to work. Python 2.7 is installed and I am running from the autotest directory. It isn't obvious to me how the PYTHONPATH variable is supposed to be set, but I pointed it to the python directo

Re: [gdal-dev] New OGR driver for DB2 Spatial support

Le lundi 26 octobre 2015 18:48:47, David Adler a écrit : > I am close to finished with this driver which was delayed significantly > getting access to a DB2 for z/OS test environment to verify that it > works across IBM DB2 platforms. > > What is the proper way to handle authorship in the source c

Re: [gdal-dev] New OGR driver for DB2 Spatial support

I am close to finished with this driver which was delayed significantly getting access to a DB2 for z/OS test environment to verify that it works across IBM DB2 platforms. What is the proper way to handle authorship in the source code? The DB2 driver is based on the MS SQL driver with signific

Re: [gdal-dev] New OGR driver for DB2 Spatial support

> > 3. What is the plan for the transition to GDAL 2.0? My driver was > > developed against GDAL 1.11.2 and parallels similar drivers for MSSQL, > > PostGIS, Oracle, etc. > > Current trunk is 2.0, 2.1dev actually ;-) > with a release candidate out. You may have to > do a little work to update

Re: [gdal-dev] New OGR driver for DB2 Spatial support

Patch is a diff of the source tree: https://en.wikipedia.org/wiki/Patch_%28Unix%29 Yours will mostly be new files, but a few will change. Easiest way to to do that is with svn checkout the trunk, make your changes, svn add them, then do svn diff > db2.patch. That makes it easier for the gdal de

Re: [gdal-dev] New OGR driver for DB2 Spatial support

David On Fri, Jun 12, 2015 at 11:33 AM, David Adler wrote: > I have mostly completed the driver for DB2 Spatial using the ODBC support > and would appreciate pointers into the GDAL information for the following: > > 1. Is there a test suite / framework for OGR drivers? Yes, you can download the

[gdal-dev] New OGR driver for DB2 Spatial support

I have mostly completed the driver for DB2 Spatial using the ODBC support and would appreciate pointers into the GDAL information for the following: 1. Is there a test suite / framework for OGR drivers? 2. What is the mechanism for submitting a new driver? 3. What is the plan for the transition

Re: [gdal-dev] New OGR Driver for MongoDB

ind the source code in my github >> https://github.com/geosky/mongodb-gdal-driver >> glad if you could join in the mongogis group i set up in the github, we may >> have some discusses there. >> >> thanks, >> shuai >> >> From: Nicol He

Re: [gdal-dev] New OGR Driver for MongoDB

ady to use. yours, shuai From: Nicol Hermann [mapser...@geoworld.de] Sent: Wednesday, May 21, 2014 3:08 PM To: Zhang, Shuai Subject: Re: [gdal-dev] New OGR Driver for MongoDB Hello shuai, me again. I checked out the Mongo driver from the Git repository but have some trouble which steps are nec

Re: [gdal-dev] New OGR Driver for MongoDB

Shuai On Wed, Apr 30, 2014 at 7:55 AM, Zhang, Shuai wrote: > Hi there, > > I wrote a ogr driver for mongodb and wish to contribute to the community. > but I'm not sure where to start and how to do it. You can file a ticket for a new feature here: http://trac.osgeo.org/gdal/newticket Attach the

[gdal-dev] New OGR Driver for MongoDB

Hi there, I wrote a ogr driver for mongodb and wish to contribute to the community. but I'm not sure where to start and how to do it. Is there anyone who can give me a hand or some guidance about it? it will be terrific if you know geojson driver or couchdb driver well, so that we may have discuss

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

> > There are different schools on the topic. I know Frank is not too keen on > mentionning versionning, although personnaly, I try to mention version > differences in the format page itself (http://www.gdal.org/ogr/drv_osm.html > mentions GDAL/OGR >= 1.10.0). But at the end, in drivers with a lo

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Selon Jeff McKenna : > On 13-01-08 9:26 PM, Even Rouault wrote: > > Ah ok, so I must mention that the online documentation is always up-to-date > > with the latest trunk version (it is refreshed each night). So the fact > that > > something is documented is not a sign of stability by itself. It ca

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

On 13-01-08 9:26 PM, Even Rouault wrote: > Ah ok, so I must mention that the online documentation is always up-to-date > with the latest trunk version (it is refreshed each night). So the fact that > something is documented is not a sign of stability by itself. It can be a new > development comm

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Le mercredi 09 janvier 2013 02:11:21, Stefan Keller a écrit : > Even, > > Thanks for the fast response! > > 2013/1/9 Even Rouault : > > (Just curious what in the doc makes you call it "stable", and what you > > consider as "stable") > > Just the fact that it's there and especially that is't also

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Even, Thanks for the fast response! 2013/1/9 Even Rouault : > (Just curious what in the doc makes you call it "stable", and what you > consider as "stable") Just the fact that it's there and especially that is't also in the overview table alongside with all other (stable) drivers http://www.gdal

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Le mercredi 09 janvier 2013 01:02:22, Stefan Keller a écrit : > Hi Even > > Documentation of OpenStreetMap driver suggest its stable (Just curious what in the doc makes you call it "stable", and what you consider as "stable") > - but when I > recently installed the newest OGR version on a linux

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Hi Even Documentation of OpenStreetMap driver suggest its stable - but when I recently installed the newest OGR version on a linux it was'nt there. Is it not yet stable enough? If not, what do you recommend? Should I include the tagged version (currently 1.9.2) and add the trunk version (subdirect

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Le mercredi 24 octobre 2012 09:57:58, Frank Broniewski a écrit : > Hi, > > I had this up my schedule for this week, but I see I need GDAL >= 2.0. > Where might I get this? From svn (https://svn.osgeo.org/gdal/trunk/gdal)? Yes, svn trunk = GDAL 2.0dev.

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Hi, I had this up my schedule for this week, but I see I need GDAL >= 2.0. Where might I get this? From svn (https://svn.osgeo.org/gdal/trunk/gdal)? Thanks, Frank Am 2012-10-17 11:54, schrieb Even Rouault: Selon Frank Broniewski : Hi Even, I need to reinstall my OSM database due to the l

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Selon Frank Broniewski : > Hi Even, > > I need to reinstall my OSM database due to the license change to ODBL. > Usually I use osm2pgsql for that, but I am willing to sacrifice a little > downtime of my DB in order to test the GDAL implementation. Before > storming ahead I wanted to know how far y

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Hi Even, I need to reinstall my OSM database due to the license change to ODBL. Usually I use osm2pgsql for that, but I am willing to sacrifice a little downtime of my DB in order to test the GDAL implementation. Before storming ahead I wanted to know how far you are with the driver implement

Re: [gdal-dev] New OGR driver: Imageset

Would it be possible to combine this with VRT XML such that when the images were read to build the VRT file that it also added the EXIF tags there. This would collect all the info into the VRT file and avoid re-reading all the individual images. Sorry this might be a dumb question as I'm not su

Re: [gdal-dev] New OGR driver: Imageset

> Even, > > I'm not convinced that a distinct EXIF domain is the best way to go. > Non-default metadata domains are often not carried with images > during translation or other processing and are (imho) more appropriate > for data that would no longer apply to transformed imagery or that is > bulky

Re: [gdal-dev] New OGR driver: Imageset

On Mon, Jul 23, 2012 at 1:48 AM, Even Rouault wrote: > Metadata (EXIF): > [...] > EXIF_GPSLatitude=(77) (5) (60) > EXIF_GPSLatitudeRef=S > EXIF_GPSLongitude=(34) (12) (0) > EXIF_GPSLongitudeRef=E > [..] > > Are you thinking to other raster formats to extract EXIF info from? To my > knowled

Re: [gdal-dev] New OGR driver: Imageset

Hi, I agree that such a provider would probably slow - too slow for a server, unless the data is cached somewhere (e.g. sqlite) and ogr only reads new/updated files, and the rest from the cache. On the other hand it would still be useful for conversion into other formats, where speed perhaps

Re: [gdal-dev] New OGR driver: Imageset

/osgeo-org.1560.n6.nabble.com/gdal-dev-New-OGR-driver-Imageset-tp4989980p4990271.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset

Hi Daniel, Thanks for your comments. Your concerns are valid about the performance. But writing a script to convert images to shapefiles would likely provide similar performance. With regards to the usability, having a driver (and the use of ogr2ogr) would be more convenient even if that's used mo

Re: [gdal-dev] New OGR driver: Imageset (Tamas Szekeres)

Daniel, Thanks for the input, I'm still thinking whether an offline or an online solution would be more sufficient. OGR driver would somewhat be simple even if it's used to convert the data source to shapefile directly (ogr2ogr). Scripting requires the user to set up further environments (Python,

Re: [gdal-dev] New OGR driver: Imageset

ssette > Envoyé : lundi 23 juillet 2012 17:27 > À : gdal-dev@lists.osgeo.org > Objet : Re: [gdal-dev] New OGR driver: Imageset > > > If I understand correctly, in the Open() call, this driver would open > each image file to read its EXIF info and index the files in memory? &

Re: [gdal-dev] New OGR driver: Imageset

At one point I used GDAL's ability to access EXIF data along with sed and bash to make a shapefile photo index, like ogrtindex but for photos and points rather than geo-rasters and polygons. It worked ok but had precision issues and I stopped working on it when I found GPSPrune, http://activitywor

Re: [gdal-dev] New OGR driver: Imageset

-- De : gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org]De la part de Daniel Morissette Envoyé : lundi 23 juillet 2012 17:27 À : gdal-dev@lists.osgeo.org Objet : Re: [gdal-dev] New OGR driver: Imageset If I understand correctly, in the Open() call, this driver would open

Re: [gdal-dev] New OGR driver: Imageset

If I understand correctly, in the Open() call, this driver would open each image file to read its EXIF info and index the files in memory? This would work fine with a dozen images, but as the number of images increases the performance will suffer a lot and this would become unusable in apps suc

Re: [gdal-dev] New OGR driver: Imageset (Tamas Szekeres)

Hi Tamas, Sounds like a great idea. I don't know if it's of use but I recently put together a python script to create KMZ files of geotagged photos using the Python Imaging Library to read EXIF data. It also exports a list of photos and coordinates as a CSV file, for loading into a GIS. You co

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Even Rouault wrote: 23. heinäkuuta 2012 13:27 > Le lundi 23 juillet 2012 00:09:05, Jukka Rahkonen a écrit : >> Even Rouault mines-paris.org> writes: >> > > > However, select with SQL feels sub-optimal. >> > > >> > > Yes, when you use ogr2ogr with explicit layer names, there are >> > > optimizatio

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Le lundi 23 juillet 2012 00:09:05, Jukka Rahkonen a écrit : > Even Rouault mines-paris.org> writes: > > > > However, select with SQL feels sub-optimal. > > > > > > Yes, when you use ogr2ogr with explicit layer names, there are > > > optimizations. For example, when you only specify the layer 'poi

Re: [gdal-dev] New OGR driver: Imageset

Le lundi 23 juillet 2012 11:27:01, Tamas Szekeres a écrit : > Hi Even, > > I just want to use the directory name to define the connection to the > images, we could also provide to scan the files in subdirectories if > needed. Do you imagine something like : ogrinfo my_directory_with_images or

Re: [gdal-dev] New OGR driver: Imageset

Hi Even, I just want to use the directory name to define the connection to the images, we could also provide to scan the files in subdirectories if needed. I would prefer to have a new driver not just an offline tool for creating OGR datasets, in this case many existing applications (like MapServe

Re: [gdal-dev] New OGR driver: Imageset

Hi Andreas, Yes I wanted to expose further information, too. It could probably be user configurable. The driver would be read only, the EXIF would be extracted by using the corresponding GDAL drivers. The site you refer to is very interesting,. This is something that we'd like to achieve. It is al

Re: [gdal-dev] New OGR driver: Imageset

Le lundi 23 juillet 2012 09:51:14, Tamas Szekeres a écrit : > Hi All, > > We're thinking about implementing a new OGR driver which would represent a > set of images as a vector data source. The images are taken from any GPS > compatible mobile device, and each picture would be represented as a poi

Re: [gdal-dev] New OGR driver: Imageset

Hi Tamas, That would be interesting. So the user could specify a folder with images and GDAL would create an OGR layer that would expose the photo location? The OGR feature would have certain EXIF data exposed as attributes? If you work on this, could you also expose other EXIF data, such as

[gdal-dev] New OGR driver: Imageset

Hi All, We're thinking about implementing a new OGR driver which would represent a set of images as a vector data source. The images are taken from any GPS compatible mobile device, and each picture would be represented as a point feature, the positions would be extracted from the exif information

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Even Rouault mines-paris.org> writes: > > > > > > However, select with SQL feels sub-optimal. > > > > Yes, when you use ogr2ogr with explicit layer names, there are > > optimizations. For example, when you only specify the layer 'points', the > > OSM driver will not even try to index the node

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

> > However, select with SQL feels sub-optimal. > > Yes, when you use ogr2ogr with explicit layer names, there are > optimizations. For example, when you only specify the layer 'points', the > OSM driver will not even try to index the nodes into the temporary > database because it is not needed.

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Rahkonen Jukka mmmtike.fi> writes: > > > Even Rouault wrote: > > > Do you have comparisons of the performance with osm2pgsql on the same PC and > > with the same data ? I'd be curious if that slow down effect is found with every > > tool, or if it is something specific to the way sqlite is

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Even Rouault wrote: >> Windows 7, 64-bit, SATA disk and 2x3 GHz is converting Finland.osm.pbf in >> about >> 8 minutes for me. But execution time does not increase at all linearly. >> Germany.osm.pbf is about 10 times larger in filesize but ogr2ogr had to work >> about 8 hours with it, thus rough

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Even Rouault wrote: >> Amenity is included in my osmconf.ini and it can be used inside -sql. >> However, your example gives me this >> >> ERROR 1: 'amenity' not recognised as an available field. >> FAILURE: SetAttributeFilter(amenity='toilets') failed. > Hum, I think I know what's wrong. I see th

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

> > Windows 7, 64-bit, SATA disk and 2x3 GHz is converting Finland.osm.pbf in > about > 8 minutes for me. But execution time does not increase at all linearly. > Germany.osm.pbf is about 10 times larger in filesize but ogr2ogr had to work > about 8 hours with it, thus roughly 70 times longer. Obvio

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

> Amenity is included in my osmconf.ini and it can be used inside -sql. > However, your example gives me this > > ERROR 1: 'amenity' not recognised as an available field. > FAILURE: SetAttributeFilter(amenity='toilets') failed. Hum, I think I know what's wrong. I see that, even if a subset of lay

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Even Rouault mines-paris.org> writes: > > Selon Jukka Rahkonen mmmtike.fi>: ... > > > It is > > much faster to convert all the points than select only a part of those. The > > error message suggest that ogr2ogr is inspecting the input file more closely > > than necessary for this use case:

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Even Rouault mines-paris.org> writes: > > Hi, > > Following the recent brainstorming with Jukka, I've pushed into trunk a > driver > to read OpenStreetMap .osm / .pbf files . . > > Testing with larger areas, like whole France or Europe, shows sluggish > performance when ways are

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

> Even Rouault mines-paris.org> writes: >> Following the recent brainstorming with Jukka, I've pushed into trunk a >> driver >> to read OpenStreetMap .osm / .pbf files . > Fascinating. Actually I think once someone imports the points, lines, polys into a DB, then (cool!) someone could then

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Selon Jukka Rahkonen : > Even Rouault mines-paris.org> writes: > > > > > Hi, > > > > Following the recent brainstorming with Jukka, I've pushed into trunk a > driver > > to read OpenStreetMap .osm / .pbf files . > > Driver seems to do what it promises. It is super fast in converting POI data > be

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Even Rouault mines-paris.org> writes: > > Hi, > > Following the recent brainstorming with Jukka, I've pushed into trunk a > driver > to read OpenStreetMap .osm / .pbf files . Driver seems to do what it promises. It is super fast in converting POI data because it is possible to skip the slowe

[gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Hi, Following the recent brainstorming with Jukka, I've pushed into trunk a driver to read OpenStreetMap .osm / .pbf files . No particularly exotic dependencies : SQLite (and Expat for OSM XML files) See http://www.gdal.org/ogr/drv_osm.html for the details (will be available in a few hours).

[gdal-dev] New OGR driver to read (French) EDIGEO exchange format

Hi all, I wanted to mention that a new OGR driver has been added into GDAL/OGR trunk (1.9.0dev) to read files in the (French) EDIGEO exchange format. It has been mainly developed/tested for EDIGEO exchanges of the Plan Cadastral Informatisé (Digital Cadastral Plan). As I have few test data, I

[gdal-dev] New OGR driver to write PostgreSQL dumps

Hi all, I just wanted to mention for those interested that a new driver has landed in GDAL/OGR svn trunk (target release : 1.8.0). It is called PGDump and offers features quite similar to the PostGIS shp2pgsql utility, that is to say the capability of dumping the INSERT / COPY statements into a

Re: [gdal-dev] New OGR Driver

On Fri, Aug 21, 2009 at 5:03 AM, Even Rouault wrote: > Selon Leonardo Piga : > > Leonardo, > > the general way to proceed and a few recommandations are described here : > http://trac.osgeo.org/gdal/wiki/HowToContribute Thanks. I'll check. > > I'm just curious : does this effort of creating maps fo

Re: [gdal-dev] New OGR Driver

Selon Leonardo Piga : Leonardo, the general way to proceed and a few recommandations are described here : http://trac.osgeo.org/gdal/wiki/HowToContribute I'm just curious : does this effort of creating maps for Brazilian cities relate somehow with the OpenStreetMap project or is it a completely

[gdal-dev] New OGR Driver

Hello, I'm implementing a new driver for OGR. The driver is responsible for handling with GPSTrackMaker files . GTM files. This program is extensively used in Brazil on a project called Tracksource. This community makes maps from Brazilian cities and distributes them freely

[gdal-dev] New OGR driver for GeoRSS

Folks, for those interested, a new OGR driver for reading and writing (Geo)RSS feeds has just landed in subversion trunk (= 1.7.0dev ...). See http://trac.osgeo.org/gdal/ticket/2726 and http://gdal.org/ogr/drv_georss.html for details. Even ___ gdal-d