Re: [gdal-dev] Ogr2ogr

2011-11-17 Thread Luca Sigfrido Percich
Hi Fred, Il giorno mer, 16/11/2011 alle 10.11 -0700, Fred Jones ha scritto: Hi Sig, I have a SQL table temp_sublocs_btc with the MT State Plane x and y as the first columns in the table. CENSUS_2010 is a sql spatial database. This is the command I have so far. When I execute it, I just

[gdal-dev] Re: OGR Driver for Norwegian SOSI standard

2011-11-17 Thread relet
Update: The source code to FYBA is available at http://bitbucket.org/relet/fyba Some binaries for FYBA and ogr+sosi are also available in the releases directory. I would still strongly vouch for integrating with ogr, as third applications like QuantumGIS or mapserver would depend on libraries

Re: [gdal-dev] Re: OGR Driver for Norwegian SOSI standard

2011-11-17 Thread Even Rouault
Thomas, I can see 2 levels of integration : 1) Using FYBA as an external library, and adding the support to link to it in GDAL makefiles/configure 2) Incorporating FYBA source code directly in GDAL SVN like done for MITAB, AVCE00, PCIDSK SDK, etc.. Which one are you targetting ? As I wrote in

[gdal-dev] Re: OGR Driver for Norwegian SOSI standard

2011-11-17 Thread relet
Thank you Even, I would want to try and go for the second option. My motivation is mainly that a majority of users will be using packaged software like osgeo4w or qgis - if SOSI support is enabled by default, it would be available in these packages. My main question is in how far the included

Re: [gdal-dev] Re: OGR Driver for Norwegian SOSI standard

2011-11-17 Thread Even Rouault
Thomas, I would want to try and go for the second option. My motivation is mainly that a majority of users will be using packaged software like osgeo4w or qgis - if SOSI support is enabled by default, it would be available in these packages. Yes that's understandable. That goal could be

Re: [gdal-dev] Re: OGR Driver for Norwegian SOSI standard

2011-11-17 Thread Mateusz Łoskot
On 17 November 2011 14:28, Even Rouault even.roua...@mines-paris.org wrote: My main question is in how far the included code has to follow RFC 8. It would be quite a task to make it follow the gdal-Hungarian prefix dialect, or even to translate variables and method names to plain English.

Re: [gdal-dev] Re: OGR Driver for Norwegian SOSI standard

2011-11-17 Thread Even Rouault
Selon Mateusz Łoskot mate...@loskot.net: On 17 November 2011 14:28, Even Rouault even.roua...@mines-paris.org wrote: My main question is in how far the included code has to follow RFC 8. It would be quite a task to make it follow the gdal-Hungarian prefix dialect, or even to translate

Re: [gdal-dev] Ogr2ogr

2011-11-17 Thread Fred Jones
This is what I have so far. Back to where I started. The table is created in CENSUS_2010 spatial database, but the ogr_geometry column is null. No error. ogr2ogr -overwrite -s_srs EPSG:32002 -t_srs EPSG:4326 -f MSSQLSpatial MSSQL:server=ELMER;database=CENSUS_2010;;trusted_connection=yes

Re: [gdal-dev] Ogr2ogr

2011-11-17 Thread Chaitanya kumar CH
Fred, Check if your source table is being read correctly. Use ogrinfo. ogrinfo -al MSSQL:server=ELMER;database=HT_2011_10;trusted_connection=yes OGR doesn't read the MSSQL geometries if the source table doesn't have an entry in the geometry_columns table. You can bypass this by using the

Re: [gdal-dev] Ogr2ogr

2011-11-17 Thread Fred Jones
Here is ogrinfo returned: INFO: Open of `MSSQL:server=ELMER;database=HT_2011_10;trusted_connection=yes' using driver `MSSQLSpatial' successful. Here is my revised command: ogr2ogr -overwrite -s_srs EPSG:32002 -t_srs EPSG:4326 -f MSSQLSpatial

Re: [gdal-dev] Ogr2ogr

2011-11-17 Thread Chaitanya kumar CH
Fred, Now I see the problem. Your columns xloc and yloc are not really geometry columns. They are just a part of the point geometry. We need to make a geometry out of them. If it was PostGIS, I would have just used the ST_GeomFromText() function to combine those two columns into a point

Re: [gdal-dev] Ogr2ogr

2011-11-17 Thread Fred Jones
There is a GEOGRAPHY::STGeomFromText('POINT(x,y)', srid) function in sql server spatial. However, when I issue the command: ogr2ogr -overwrite -s_srs EPSG:32002 -t_srs EPSG:4326 -f MSSQLSpatial MSSQL:server=ELMER;database=CENSUS_2010;trusted_connection=yes

Re: [gdal-dev] Ogr2ogr

2011-11-17 Thread Fred Jones
I think I was using the wrong spatial function. There is a STPointFromText function. However, when I try the following from SQL test (without OGR and using plug values for Montana State Plane NAD 27, and no SRID since I understand it should be zero) : select geography::STPointFromText('POINT(' +

[gdal-dev] gdaldem color-relief geotiff alpha band nv value not working

2011-11-17 Thread Hailey Eckstrand
Hi All, I am trying to create an RGBA geotiff using gdaldem color-relief. When I load the output geotiff into QGIS, all the NoData values appear black, so I loaded the geotiff into R (using rgdal) and all the values in the the alpha band are 255, none are 0. What am I doing wrong? Thanks in

Re: [gdal-dev] Ogr2ogr

2011-11-17 Thread Fred Jones
Whew...finally got it to work. Had to really unbend my mind to think through all of the great advice you folks have given me. Here's the OGR command that creates the point projection in mssql spatial: ogr2ogr -overwrite -s_srs EPSG:32002 -t_srs EPSG:4326 -f MSSQLSpatial

Re: [gdal-dev] gdaldem color-relief geotiff alpha band nv value not working

2011-11-17 Thread Even Rouault
Le jeudi 17 novembre 2011 21:48:52, Hailey Eckstrand a écrit : Hi All, I am trying to create an RGBA geotiff using gdaldem color-relief. When I load the output geotiff into QGIS, all the NoData values appear black, so I loaded the geotiff into R (using rgdal) and all the values in the the

Re: [gdal-dev] Re: OGR Driver for Norwegian SOSI standard

2011-11-17 Thread Frank Warmerdam
Folks, Even asked me to speak up if I had any thoughts on the issues raised in this thread. I had not been following it closely. I will note that: o RFC 8 on coding guidelines and such is *not* adopted and in any event it would be advisory and I would not try to apply it to

[gdal-dev] KMLSuperOverlay in Google Earth 6.1.0.5001

2011-11-17 Thread Roland Duhaime
Has anyone else experienced the latest version of Google Earth (6.1.0.5001) or the G.E. API not loading PNG formatted KMLSUPEROVERLAYs created using gdal_translate? The same KMZ files worked in the past. Thanks, Roland ___ gdal-dev mailing list

Re: [gdal-dev] KMLSuperOverlay in Google Earth 6.1.0.5001

2011-11-17 Thread Roger André
What is the output of gdalinfo on one of the PNG's in the superoverlay? On Thu, Nov 17, 2011 at 1:36 PM, Roland Duhaime roland.duha...@gmail.comwrote: Has anyone else experienced the latest version of Google Earth (6.1.0.5001) or the G.E. API not loading PNG formatted KMLSUPEROVERLAYs

[gdal-dev] GMLJP2 question

2011-11-17 Thread Reynolds, Scott
Hi, I have a JP2 image whose extent is supposed to be from (0E deg , 0N deg) to (10E deg, 10N deg) but gdalinfo (from FWTools 2.4.7) is reporting extents that are off by 0.5 pixel north and west. The GML identifies the origin of the image as (0E deg, 10N deg). My understanding is that GDAL

Re: [gdal-dev] GMLJP2 question

2011-11-17 Thread Frank Warmerdam
Scott, Examining gdal/gcore/gdaljp2metadata.cpp it is clear the code believe that the GML rectified grid origin is the center of the top left pixel and adjusts accordingly. This is something we worked on pretty carefully during the GMLJP2 interoperability experiment with OGC a few years ago so I

Re: [gdal-dev] ogr2ogr reprojection, features are not transformed

2011-11-17 Thread Etienne Tourigny
Hello On Wed, Nov 16, 2011 at 5:09 PM, Even Rouault even.roua...@mines-paris.org wrote: Etienne, It seems that setting source srs is needed when using shapefiles, as you said.  This should be documented somewhere (probably on the ogr2ogr page and/or shapefile driver page). Feel free to