Re: [gdal-dev] Appending to a single feature class in a gdb via ogr2ogr
Hi Maggie,
On Mon, Apr 27, 2020 at 9:03 AM Maggie Wooten wrote:
>
> First, I apologize if I am using this mailing list improperly. This is my
> first time here.
Asking questions is an appropriate use of the list.
>
> I am trying to iterate over some shapefiles (109 shapefiles to be exact) and
> append them to a *single* feature class in an output geodatabase, but the
> resulting output geodatabase is one with 100 feature classes that looks like
> this:
>
Do all the shapefiles have (exactly) the same fields? If not, it
probably won't work.
> INFO: Open of `output.gdb' using driver `FileGDB' successful.
> 1: output (Multi Polygon)
> 2: output_1 (Multi Polygon)
> 3: output_1_2 (Multi Polygon)
> 4: output_1_2_3 (Multi Polygon)
> 5: output_1_2_3_4 (Multi Polygon)
> .
> 99:
> output_1_2_3_4_5_6_7_8_9_10_11_12_13_14_15_16_17_18_19_20_21_22_23_24_25_26_27_28_29_30_31_32_33_34_35_36_37_38_39_40_41_42_43_44_45_98
> (Multi Polygon)
> 100:
> output_1_2_3_4_5_6_7_8_9_10_11_12_13_14_15_16_17_18_19_20_21_22_23_24_25_26_27_28_29_30_31_32_33_34_35_36_37_38_39_40_41_42_43_44_45_99
> (Multi Polygon)
>
>
> These are the commands I'm running in the iteration:
>
> if i == 0: "ogr2ogr -nln output -a_srs EPSG:4326 -t_srs EPSG:4326 -f
> "FileGDB" output.gdb input1.shp"
>
> else: "ogr2ogr -nln output -a_srs EPSG:4326 -t_srs EPSG:4326 -update -append
> -f "FileGDB" output.gdb inputX.shp"
>
>
> What am I doing wrong here? How can I get the desired result? I tried a bunch
> of different things and flags and still could not get it all to append to one
> feature class. Any advice would be greatly appreciated and I'd be happy to
> provide whatever information may be necessary.
>
I'm not quite sure what is going wrong there. I didn't try with an
output of FileGDB but did something similar all with shapefiles. The
final resulting combined shapefile could probably be manually
ogr2ogr'ed into a FileGDB.
I did this on Ubuntu using Bash. If you're using a different shell,
you will need different command syntax. Specifically variables,
filenames without extensions, quoting, escape characters and other
things all need adjustment. Complicated filenames with spaces or
other symbols can make this more difficult too.
mkdir merged
This is to make an "empty" shapefile with the correct fields and types
and an additional field named s_file to put the source file name in
later:
ogr2ogr -sql "select *, '' as s_file from
Surveys_Invalid_ManualFix_7of7 where SURVEYID='fake'"
merged/surveys_v1.shp Surveys_Invalid_ManualFix_7of7.shp -nln
surveys_v1
This is to check that my empty shapefile turned out okay:
ogrinfo merged/surveys_v1.shp -al
(I worked in a directory where I was selecting ALL the shapefiles, all
of which have the same fields):
FILES=*.shp
for f in $FILES; do g=${f%%.*}; ogr2ogr -sql "select *, '$g' as s_file
from $g" -update -append merged/surveys_v1.shp $f -nln surveys_v1;
done
This is to check that my shapefile is no longer empty and turned out okay:
ogrinfo merged/surveys_v1.shp -al
If you are using DOS on windows, here is a note (untested) from some
previous work. I don't have windows readily available to test it (the
% might need to be %%):
for %f in (*.shp) do ogr2ogr -sql "select *, '%~nf' as s_file from
%~nf" -update -append merged\output.shp %f -nln output
Hope that helps.
Best regards, Eli
> Thank you!
> Ma
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_viewshed
Hi Pedro, On Thu, May 7, 2020 at 4:03 PM Pedro Venâncio wrote: > > Hi, > > I'm trying the new gdal_viewshed and it is in fact really quick! But the > result is completely different than other viewshed analysis algorithms: > > https://cld.pt/dl/download/e80216bb-d7eb-40b0-b6da-8e45572e9eb3/viewshed.jpg > > https://cld.pt/dl/download/ee993a0b-cf86-462a-b831-307aecde7865/viewshed2.jpg > > GRASS and Visibility Analysis plugin for QGIS have almost the same result. > The result from gdal_viewshed seems completely overrated. The options I'm > using are [almost] the same in both algorithms. > > gdal_viewshed -b 1 -md 28000.0 -ox -41597.922 -oy 71254.049 -oz 21.6 -tz 10.0 > -vv 1 -cc 0.85714 -f GTiff path_to_mdt.tif path_to_output.tif > Does -tz 10.0 in effect raise your DEM target elevation by 10 units? Was the same done in GRASS and the Visibility Analysis plugin for QGIS? Was the observer height of -oz 21.6 the same for all three as well? Best regards, Eli > Has anyone else this experience? > > Thanks! Best regards, > Pedro Venâncio > > > Howard Butler escreveu no dia quinta, 7/05/2020 à(s) 17:41: >> >> >> >> > On May 7, 2020, at 11:05 AM, Eli Adam wrote: >> > >> > The image with two dots makes me think that there can be multiple >> > observer inputs. Is that the case? Is the syntax for that just to >> > keep adding more -ox, -oy, (and oz)? For instance, gdal_viewshed -md >> > 500 -ox -10147017 -oy 5108065 -ox -10147117 -oy 5108165+100 source.tif >> > destination.tif >> >> The picture is a poor example. You can't do multiple obvservers, but you can >> run a bunch of masks together and then merge to get a multipoint viewshed. I >> indeed made two masks with gdal_viewshed and then merged them together to >> make that picture. >> >> That picture or the docs should maybe be updated to reflect a more common >> scenario with better description. File a ticket and attach some language and >> pictures to it as you start playing with it and we can merge it. >> >> Thanks, >> >> Howard >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Eli L Adam, PLS Lincoln County Surveyor's Office 880 NE 7th Street Newport, OR 97365 541-574-1289 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_viewshed
Congrats on another great release! On Thu, May 7, 2020 at 7:20 AM Even Rouault wrote: > > > The 3.1.0 release is a new feature release with the following highlights: > > - [gdal_viewshed](https://gdal.org/programs/gdal_viewshed.html): > > new utility for viewshed algorithm > On the documentation of this, it says: [with the image with two dots] A computed visibility for two separate -ox and -oy points on a DEM. gdal_viewshed -md 500 -ox -10147017 -oy 5108065 source.tif destination.tif The image with two dots makes me think that there can be multiple observer inputs. Is that the case? Is the syntax for that just to keep adding more -ox, -oy, (and oz)? For instance, gdal_viewshed -md 500 -ox -10147017 -oy 5108065 -ox -10147117 -oy 5108165+100 source.tif destination.tif Best regards, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reconsidering release cycle length ?
On Mon, Apr 27, 2020 at 10:20 AM Even Rouault wrote: > > > One year between feature versions is quite a lot. Perhaps 6 months would be a > good compromise between having enough time to mature a complex feature and > faster delivery of it to people not directly consuming master. A consequence > of this is that our usual policy of supporting the last released branch > during the development cycle of the next release would also go to 6 month (to > avoid supporting too many branches at the same time), or perhaps even 4 (see > below example) > > I've also heard voices wishing to have more frequent bugfix releases. Every 2 > months could be reasonable. > > Of course depending on what comes to master, things could be reconsidered to > let a bit more time for maturing a feature if needed, so 6 months is more an > indication than a firm delay. This is also dependent on people doing the > actual work. I'll do my share, but help always welcome. > Perhaps another perspective on this is that since GDAL has a longer release cycle, supports releases for a long time, is a fairly innovative library with new drivers, new features, and improvements; it compels people to track master and engage the project. This provides reliable testing for the project on various compilers, hardware architecture, novel driver combinations, conflicts with other software, and many other things that won't ever be fully covered in CI type things. If people were not compelled to track master, then this engagement with the project might be reduced or pushed to releases with a less interactive feedback (i.e. they won't be testing patches or recent commits). From my own personal experience, GDAL has been the only project worth tracking master and engaging in this way. Other projects, I wait for the release and take a binary and am less in a position to provide testing or meaningful feedback. Tracking master and engaging with GDAL has been a rewarding experience for me over the years. Just another way to look at this. I'm not sure if release cycle would impact the number of people tracking master or the level of engagement there but it might be worth considering. I notice mostly Even's work on releases. People wanting bug releases more frequently could start by helping on releases. Best regards, Eli > > > Thoughts ? > > > > Even > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Doc: driver + config options summary pages [was Re: How to know which formats allow editing with ogrinfo?]
On Sun, Nov 17, 2019 at 5:42 PM Eli Adam wrote: > > https://gdal.org/drivers/raster/index.html > > https://gdal.org/drivers/vector/index.html These two tables have been updated. Please check them over. Let me know if anything needs to be changed/updated. Best regards, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Doc: driver + config options summary pages [was Re: How to know which formats allow editing with ogrinfo?]
On Sat, Nov 16, 2019 at 9:12 AM Even Rouault wrote: > > > > If so, then yes if someone contributes it, that'd be welcome. However I > > > think we'd want it to be generated from a Python script from the > > > individual .rst pages, by parsing the directives like ".. > > > supports_create::" that are in those .rst files. That way that would make > > > maintainance of the summary easier (and initial version less tidious that > > > doing that manually) > > OK, so I've added two new directives > > .. built_in_by_default:: > > or > > .. build_dependencies:: put here dependencies name > > and just used them on a couple drivers for demo: > https://github.com/OSGeo/gdal/commit/0b3b1ed25bdde6f49a6515e0431d78bc9729ff83 > > A script that fetches all the information from individual pages > is run automatically at each documentation build and generates a summary table > at > https://gdal.org/drivers/raster/index.html > https://gdal.org/drivers/vector/index.html > > ==> What remains to be done is to go through all driver .rst pages and add > .. built_in_by_default:: or .. build_dependencies:: where appropriate so that > no "???" remains > > Volunteers ? If the old table is a reliable source, I can do a good portion of them. > > > > Migrating the wiki page to the doc could be useful. My own opinion is that > > > driver specific configuration options should be documented in the driver > > > specific page, rather than in a global config option page. Same with /vsi > > I've also added a specific role when you use a configuration option > > :decl_configoption:`FOO` > > Example of use: > > https://github.com/OSGeo/gdal/commit/c8fcb6d941c0251219dbd57f701e5b161ce5085e > > Similarly to the driver list, a script is run at each build to generate an > index of declared configuration options (if several pages declare the same > config option, several links will be created). The result is there: > > https://gdal.org/user/configoptions_index.html > > ==> What remains to be done is tag appropriately configuration options > wherever they are already mentionned and add missing ones. > > Volunteers ? I can work on some already mentioned ones. Thanks for adding this. Best regards, Eli > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to know which formats allow editing with ogrinfo?
On Fri, Nov 15, 2019 at 9:55 AM Even Rouault wrote: > > > The old driver pages > > (https://web.archive.org/web/20190211030817/https://www.gdal.org/ogr_formats > > .html) were tables that very effectively conveyed the capabilities (or > > limitations) of the drivers and allowed for scanning for drivers that > > had the capabilities that you wanted. > > The information in individual pages is roughly the same as in the global > table. > > > Would a similar table be possible or desirable? > > A few people have indeed noted the absence of the table. Not sure if this is > usual "resistance to change" phenomenon or if there is there really a strong > use case for "I don't want which format to use: let's look at the summary page > to select one". I've certainly found myself shopping for a format with that table. Usually some middle format in an ETL toolchain, sometimes complicated by cross platform considerations for driver availability. > > If so, then yes if someone contributes it, that'd be welcome. However I think > we'd want it to be generated from a Python script from the individual .rst > pages, by parsing the directives like ".. supports_create::" that are in those > .rst files. That way that would make maintainance of the summary easier (and > initial version less tidious that doing that manually) Contributing it as a python script is an opportunity for someone other than me. > > > There are a few things that might be missing. The new page has > > https://gdal.org/programs/raster_common_options.html#raster-common-options > > and > > https://gdal.org/programs/vector_common_options.html#vector-common-options > > I wonder if a list of uncommon options like this would be helpful, > > https://trac.osgeo.org/gdal/wiki/ConfigOptions? > > Migrating the wiki page to the doc could be useful. My own opinion is that > driver specific configuration options should be documented in the driver > specific page, rather than in a global config option page. Same with /vsi I'll try moving some of these over and see how it goes. > specific options that should go to > https://gdal.org/user/virtual_file_systems.html if not already there. > > Or if a global list is needed, I'd say a bit the same as for driver summaries, > have a way to compile the list of options from .rst files where they would be > mention and link from the summary to the actual page. But we don't have > currently any explicit directive for configuration options. I'll start with driver specific. Thanks, Eli > > > I was also curious to see if the OSGeo technical writing project would > > impact any of the documentation. > > There was initial discussion but no follow-up as far as GDAL is concerned. > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to know which formats allow editing with ogrinfo?
On Fri, Nov 15, 2019 at 3:58 AM Even Rouault wrote: > > On vendredi 15 novembre 2019 08:52:48 CET Rahkonen Jukka (MML) wrote: > > Hi, > > > > Shapefile can be edited with ogrinfo > > ogrinfo -dialect SQLite -sql "update foo set bar='14'" foo.shp > > > > GML opens always as read-only with -sql option > > ogrinfo -sql "select * from foo" foo.gml > > Had to open data source read-only. > > INFO: Open of `foo.gml' > > using driver `GML' successful. > > > > How can I know which formats support editing with -sql and which not? I > > could not find any obvious metadata by checking the capabilities of a few > > different drivers. > > There's indeed no driver-level metadata indicating support for updates (update > through SQL is just a particular case). With a dataset opened, on a layer, > with the API you can query for fine grain capabilities with > TestCapability(OLCRandomWrite/OLCDeleteFeature/etc...) Can this be partly inferred from driver pages with the presence (or absence) of items? For instance, https://gdal.org/drivers/vector/gml.html#driver-capabilities The old driver pages (https://web.archive.org/web/20190211030817/https://www.gdal.org/ogr_formats.html) were tables that very effectively conveyed the capabilities (or limitations) of the drivers and allowed for scanning for drivers that had the capabilities that you wanted. Would a similar table be possible or desirable? This got me thinking about the Sphinx migration a bit, https://lists.osgeo.org/pipermail/gdal-dev/2019-May/050273.html. It looks great and the website is easy to use. Thanks to everyone who updated that! There are a few things that might be missing. The new page has https://gdal.org/programs/raster_common_options.html#raster-common-options and https://gdal.org/programs/vector_common_options.html#vector-common-options I wonder if a list of uncommon options like this would be helpful, https://trac.osgeo.org/gdal/wiki/ConfigOptions? Same with some overview table of driver capabilities? If it is just a matter of recreating a new page copied from the old, I would be up trying to contribute to that. I lack the detailed knowledge of the drivers to be able to create it from scratch. I was also curious to see if the OSGeo technical writing project would impact any of the documentation. Best regards, Eli > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] using gdal_viewshed
Hi Ben, On Sun, Nov 10, 2019 at 3:57 AM Ben Avrahami wrote: > > Hello all, I've been trying trying to use the newest gdal_viewshed in > gdal-dev release, and I've run into an error I can't quite understand. > > The input I've been using is: > > gdal_viewshed -md 1000 -ox "691868.511" -oy "3492031.487" > It might be helpful to copy and paste your command so if there are typos or otherwise, they can be spotted. A gdalinfo report on your input file could also be helpful. That would show coordinates of the image and allow looking at things like are those coordinates within the image? Is it in the coordinate system of the image? A gdalinfo report details that nicely. > > And I get the response: > > ERROR 5: C:\temp\files\out.tif, band 1: Access window out of range in > RasterIO(). Requested > (0,-1) of size 67x1 on raster of 67x67. > ERROR 1: RasterIO error when writing target raster This makes it seem like something isn't lining up correctly. With the absence of information some random guess include: that the coordinate is not within the image, or perhaps the coordinate is less than -md 1000 units from the edge (although testing that on other data here worked fine), that there are pixel alignment/resolution issues and using coordinates not to three decimal places would work better. I see that gdal_viewshed -md 900 -ox 985710 -oy 658590 http://download.osgeo.org/gdal/data/aaigrid/095b_dem_90m.asc output2.tif works and gdal_viewshed -md 800 -ox 985710 -oy 658590 http://download.osgeo.org/gdal/data/aaigrid/095b_dem_90m.asc output3.tif fails with the error: 0ERROR 5: output3.tif, band 1: Access window out of range in RasterIO(). Requested (0,-1) of size 19x1 on raster of 19x19. ERROR 1: RasterIO error when writing target raster it seems that -md must be a multiple of the resolution. Best regards, Eli > > I get a similar error if I try to use the GDALViewshedGenerate C-API > function. The input us a valid WGS84-UTM tiff file, and the output is a valid > path, but the file does not actually exist until I run the command. After I > run the command, the output file is created but only filled halfway. Any help > at wall would be appreciated. > > regards, Ben > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Converting 3D Polygons to 2D Polygons?
On Tue, Oct 15, 2019 at 6:12 PM Brandon Biggs wrote: > Hello, > > Is there some way to convert 3D objects to 2D polygons using ogr2ogr? > > Did you already try, -dim XY More details here, https://gdal.org/programs/ogr2ogr.html#ogr2ogr What happened if you tried -dim XY? Best regards, Eli I have a large file with lots of polygons with 0 as the z coordinate. So > the point would look like [1,2,0]. > > I would like it to be: [1,2]. > > Thanks, > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Generating Viewsheds without Using Sightlines
On Mon, Sep 30, 2019 at 11:54 AM Even Rouault wrote: > > On lundi 30 septembre 2019 20:10:38 CEST Tamas Szekeres wrote: > > Hi, > > > > I've implemented a viewshed algorithm a while ago, by utilizing a modified > > version of the algorithm published at > > https://www.asprs.org/wp-content/uploads/pers/2000journal/january/2000_jan_8 > > 7-90.pdf > > > > With this approach, it was crucial to provide a fast real-time option for > > the viewshed calculation on relatively large raster DEMs by using only a > > small memory footprint. > > > > The implementation can be found here: > > > > https://github.com/szekerest/gdal/blob/viewshed/gdal/alg/viewshed.cpp > > https://github.com/szekerest/gdal/blob/viewshed/gdal/apps/gdal_viewshed.cpp > > > > Does it make sense to spend some more effort and incorporate this approach > > in GDAL officially? > > Sounds useful to me ! > (old memories of having implement line-of-sight based intervisibility > algorithm in a past life !) Gdaldem (although it has a different history) has an assortment of DEM based utilities, https://gdal.org/programs/gdaldem.html I'm not sure if it would make sense there or elsewhere. It would be a useful tool. Best regards, Eli > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [SeasonOfDocs] Offers for GDAL documenting
On Mon, Jun 17, 2019 at 5:43 AM Even Rouault wrote: > > Hi, > > this is really great news ! Given my experience with the project, I'm rather > far from being representative of someone less familiar with it or with a non- > developer profile, so thoughts from the broader GDAL community on what they > feel is the most missing would be welcome. > There are some things that are very basic that might make the documentation more understandable to a beginner. I'm not sure if these things are true or I've made them up or they are supposed to be too obvious to state. -nln = New Layer Name -nlt = New Layer Type -a_srs = assign spatial reference system -t_srs = target spatial reference system -s_srs = source spatial reference system -ot = output type -of = output format Are those true? If not, I've used them to better understand (and remember) the options. Best regards, Eli > One thing I've in mind - this is rather a detail - is that we lost a bit of > content (build requirements for each driver) during the Sphinx migration, as > pointed out by > https://github.com/OSGeo/gdal/issues/1204#issuecomment-498624481 , so this > could be a potential task. > > More generally, I feel we might need more tutorial-like / how-to style > documentation. The current documentation is hopefully rather decent as a > reference guide, but lacking on the quick-start side. On the wiki, there are > some source of information, mostly from > https://trac.osgeo.org/gdal/wiki/UserDocs , that could be interesting to > migrate partly on the main documentation, but with a critical eye (some of the > hints might be outdated due to later improvements, etc) > > Lynden, perhaps you've also suggestions from your practice of the project and > its documentation on what you'd like to see added ? > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
On Fri, Jun 12, 2015 at 11:25 AM, Ari Simmons ari.ucb.f...@gmail.com wrote: Do you mean gdal_translate -te -13813007 5569641 -13809113 5572598 srtm_merged_3857.vrt my_subwindow.tif --config GDAL_CACHEMAX 800 ? Oops, I made a bad typo by omitting -projwin: gdal_translate -projwin -13813007 5569641 -13809113 5572598 srtm_merged_3857.vrt my_subwindow.tif --config GDAL_CACHEMAX 800 Best regards, Eli On Thu, Jun 11, 2015 at 3:08 PM, Eli Adam ea...@co.lincoln.or.us wrote: On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons ari.ucb.f...@gmail.com wrote: One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ah, duh. Unit change. On Thu, Jun 11, 2015 at 2:26 PM, Ari Simmons ari.ucb.f...@gmail.com wrote: I am experimenting with using 'gdalwarp' on a .vrt (first time), but I'm not sure what I'm doing wrong. I've been running this: gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear -of VRT merged.vrt srtm_merged_3857.vrt and it processes fast (far far *too fast* for this global file) and returns That is the right speed (~0 seconds) and disk space (~0MB). That is because it doesn't actually do anything except write down notes of what it would have done (and will do in the future if you ask for it). I like testing large VRT files by outputting a subwindow tif like this: gdal_translate -13813007 5569641 -13809113 5572598 srtm_merged_3857.vrt my_subwindow.tif --config GDAL_CACHEMAX 800 If things look good on the subwindow, then it is time for all the I/O waiting, processor cycles, and storage space. Evaluating a few places, especially where tiles come together can find things early without all the wait. HTH, Eli Creating output file that is 194835P X 479814L. Processing input file merged.vrt Using internal nodata values (eg. 0) for image merged.vrt The return .vrt file definitely doesn't appear right...a quick look at the returned file: input: Size is 432000, 208800 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (-180.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) Band 1 Block=128x128 Type=Int16, ColorInterp=Gray NoData Value=0 Overviews: 216000x104400, 108000x52200, 54000x26100, 27000x13050, 13500x6525, 6750x3263, 3375x1632, 1688x816, 844x408, 422x204 and output file: Size is 193861, 479814 Coordinate System is: PROJCS[WGS 84 / Pseudo-Mercator, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]], PROJECTION[Mercator_1SP], PARAMETER[central_meridian,0], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AXIS[X,EAST], AXIS[Y,NORTH], EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs], AUTHORITY[EPSG,3857]] Origin = (-19837179.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N) Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S) Band 1 Block=512x128 Type=Int16, ColorInterp=Gray Overviews: 96931x239907, 48466x119954, 24233x59977, 12117x29989, 6059x14995, 3030x7498, 1515x3749, 758x1875, 379x938, 191x471 One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ___ 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] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)
On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons ari.ucb.f...@gmail.com wrote: One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ah, duh. Unit change. On Thu, Jun 11, 2015 at 2:26 PM, Ari Simmons ari.ucb.f...@gmail.com wrote: I am experimenting with using 'gdalwarp' on a .vrt (first time), but I'm not sure what I'm doing wrong. I've been running this: gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear -of VRT merged.vrt srtm_merged_3857.vrt and it processes fast (far far *too fast* for this global file) and returns That is the right speed (~0 seconds) and disk space (~0MB). That is because it doesn't actually do anything except write down notes of what it would have done (and will do in the future if you ask for it). I like testing large VRT files by outputting a subwindow tif like this: gdal_translate -13813007 5569641 -13809113 5572598 srtm_merged_3857.vrt my_subwindow.tif --config GDAL_CACHEMAX 800 If things look good on the subwindow, then it is time for all the I/O waiting, processor cycles, and storage space. Evaluating a few places, especially where tiles come together can find things early without all the wait. HTH, Eli Creating output file that is 194835P X 479814L. Processing input file merged.vrt Using internal nodata values (eg. 0) for image merged.vrt The return .vrt file definitely doesn't appear right...a quick look at the returned file: input: Size is 432000, 208800 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (-180.0004170,84.0004166) Pixel Size = (0.0008323,-0.0008323) Corner Coordinates: Upper Left (-180.0004167, 84.0004167) (180d 0' 1.50W, 84d 0' 1.50N) Lower Left (-180.0004167, -89.9995833) (180d 0' 1.50W, 89d59'58.50S) Upper Right ( 179.9995833, 84.0004167) (179d59'58.50E, 84d 0' 1.50N) Lower Right ( 179.9995833, -89.9995833) (179d59'58.50E, 89d59'58.50S) Center ( -0.0004167, -2.9995833) ( 0d 0' 1.50W, 2d59'58.50S) Band 1 Block=128x128 Type=Int16, ColorInterp=Gray NoData Value=0 Overviews: 216000x104400, 108000x52200, 54000x26100, 27000x13050, 13500x6525, 6750x3263, 3375x1632, 1688x816, 844x408, 422x204 and output file: Size is 193861, 479814 Coordinate System is: PROJCS[WGS 84 / Pseudo-Mercator, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]], PROJECTION[Mercator_1SP], PARAMETER[central_meridian,0], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AXIS[X,EAST], AXIS[Y,NORTH], EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs], AUTHORITY[EPSG,3857]] Origin = (-19837179.64248511900,18807657.84885524600) Pixel Size = (205.686440189378940,-205.686440189378940) Corner Coordinates: Upper Left (-19837179.642,18807657.849) (178d12' 1.50W, 84d 0' 1.50N) Lower Left (-19837179.642,-79883575.764) (178d12' 1.50W, 89d59'58.50S) Upper Right (20037399.339,18807657.849) (179d59'56.47E, 84d 0' 1.50N) Lower Right (20037399.339,-79883575.764) (179d59'56.47E, 89d59'58.50S) Center ( 100109.848,-30537958.958) ( 0d53'57.49E, 89d 2'43.78S) Band 1 Block=512x128 Type=Int16, ColorInterp=Gray Overviews: 96931x239907, 48466x119954, 24233x59977, 12117x29989, 6059x14995, 3030x7498, 1515x3749, 758x1875, 379x938, 191x471 One notably huge difference is that there is a huge jump in pixel size (from 0.0008323 to 205.686440189378940)... ___ 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] Can we combine all layers of kml into single GeoJSON
Just thinking, but wouldn't it be nice to have ogrbuildvrt tool that would take list of OGR supported layers and outputs a simple vrt with one union layer like the one in your example? There is this script, https://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/ogr2vrt.py, with details here, http://lists.osgeo.org/pipermail/gdal-dev/2009-October/022522.html. It might get you part of the way. Cheers, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Associate single point coordinates to image.
GDAL reads EXIF data and you can grab that output and then send it into an OGR output. I used to have a bash script that did that, but then I found there were some tricky things to overcome and found that GpsPrune is really good at this. GpsPrune can also correlate a GPS track and time stamped photos lacking EXIF location data. It exports KML points for the photos. ExifTool has lots of EXIF data manipulation capacity, http://www.sno.phy.queensu.ca/~phil/exiftool/ Best regards, Eli On Fri, Nov 14, 2014 at 3:38 AM, deve orante.tucc...@exprivia.it wrote: Yes. The final effect is the same: photo-- location--image over the map. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Associate-single-point-coordinates-to-image-tp5172985p5173000.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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Associate single point coordinates to image.
I think that this is generally call geotagging which might help while looking for options. Eli On Fri, Nov 14, 2014 at 9:03 AM, Eli Adam ea...@co.lincoln.or.us wrote: GDAL reads EXIF data and you can grab that output and then send it into an OGR output. I used to have a bash script that did that, but then I found there were some tricky things to overcome and found that GpsPrune is really good at this. GpsPrune can also correlate a GPS track and time stamped photos lacking EXIF location data. It exports KML points for the photos. ExifTool has lots of EXIF data manipulation capacity, http://www.sno.phy.queensu.ca/~phil/exiftool/ Best regards, Eli On Fri, Nov 14, 2014 at 3:38 AM, deve orante.tucc...@exprivia.it wrote: Yes. The final effect is the same: photo-- location--image over the map. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Associate-single-point-coordinates-to-image-tp5172985p5173000.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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAl no more compiling on Ubunut 12.0.4
It compiled GDAL on Ubuntu 12.0.4 LTS about 6 months ago. Today I updated the git sources, a new error at the very beginning of compilation stops everything Configure seems to have changed a lot. Any suggestions? I can compile svn trunk on 12.04 as of today. I started with a make clean and then this is my configure: ./configure --with-poppler --with-spatialite=yes --with-java=yes --with-mdb=yes --with-python --with-curl --with-expat --with-libkml make clean might help. There are a lot of different libraries which can be internal or external and many combinations to test so not sure how similar my setup is to yours. Best regards, Eli Cheers, Rémi-C //error// In file included from cpl_conv.h:35:0, from cpl_conv.cpp:33: cpl_port.h:89:2: error: #error Unexpected value for SIZEOF_INT cpl_port.h:93:2: error: #error Unexpected value for SIZEOF_UNSIGNED_LONG cpl_port.h:97:2: error: #error Unexpected value for SIZEOF_VOIDP ___ 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] Adding a Commercial support section on gdal.org?
Adding a support section like some other OSGeo projects is a good idea (in my opinion). This is a way for people to use the project webpage to find those who are most substantially contributing to the project and know the most about GDAL/OGR. On Thu, Aug 21, 2014 at 5:46 AM, berte...@charta.acme.com wrote: Charta is interested to be listed as experienced provider if gdal.org will ever add info about commercial support. Nevertheless, I think this item has to receive more attention, considering at least: * the license of GDAL. Using MIT license means being expecially open to commercial usage. I don't know if this is really consequential with selecting a group of commercial providers instead of being agnostic about usage of the code and technology created (I don't agree with this, but...); * usually support means choice between several tools and technologies, being a core contributor could mean some bias about recurring to a specific tool. Being listed as such could become a double-edged sword; If you are looking for GDAL/OGR support (on the gdal.org web page) you have already made your technology choice. If you are looking for support in selecting a technology you should not be looking on gdal.org but rather collecting references or otherwise doing research on appropriate support in whatever domain you're in. gdal.org is not the the proper place to look for support on javascript libraries or other non-GDAL/OGR topics. Someone may be better off with advice to use something other than GDAL/OGR but gdal.org is not the place to get that advice (the people and companies listed there may give that advice if approached but they would best know what is out of the GDAL/OGR scope). * any evaluation aobut support should be based on the help provided to the user and not about the contribution to the project. The client shoud be able to choose if he needs broad or focused support, if he needs new developments or better integration and so on. Listing experiences or specialisation (geodatabases, remote sensing and so on) could be more useful. A prudent customer might evaluate support by referrals and reviews based on help provided to the user but gdal.org is in no place to evaluate that. gdal.org is certainly in a place to evaluate and recommend those who have a history of competently contributing to the project (tickets, patches, commits, emails correctly answered, relevant presentations at FOSS4G, etc). The OSGeo Service providers directory, http://www.osgeo.org/search_profile?SET=1MUL_TECH[0]=00013 already provides a mechanism for self listing anything the person listing wants. This remains a valuable resource for researching support options but gives no indication of who is competently contributing to the project. The PostGIS support page lists focus area of support, http://postgis.net/support Best regards, Eli Even's case is noteworthy, because he is more than a Core contributor, but a project leader for GDAL. When his affiliation to École des Mines changed to his own company, Spatialys, I thought this was a very good move because he could more easily provide consulting services to commercial entities. Maybe his visibility as a prominent person in this community is already warranted, I understand that his proposal is addressed to others, but I think gdal-dev is about developing, although the list provides a lot of help to users, is this the right place? c On Thu, Aug 20, 2014 at 10:02:35 PM, Even Rouault wrote: Date: Wed, 20 Aug 2014 22:02:35 +0200 From: Even Rouault even.roua...@spatialys.com To: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org Subject: [gdal-dev] Adding a Commercial support section on gdal.org ? Message-ID: 201408202202.36022.even.roua...@spatialys.com Content-Type: Text/Plain; charset=us-ascii Hi, I'm wondering if there would be a concensus and interest to add a Commercial support section on gdal.org. A number of OSGeo projects have such page (see [1]), so that wouldn't be completely awkward to have one for GDAL as well. The OSGeo Service provider database reference 137 companies/individuals that have registered themselves as providing GDAL support ([2]) ! Pretty cool, but I'm wondering how a user not familiar with the project could effectively use that list to identify core contributors from casual advanced users. If we agree for adding a Commercial support section, the question is : on which criteria do we accept an organization/individual to be listed in the section ? We would want them to be as most objective and non debatable as possible. A simple criterion could be anyone who has commit rights (in trunk, not just in a sandbox or customer branch). There are currently 56 SVN committers. That could be strengthened with a minimum number of commits/lines changed during a period, but we perhaps don't need that
Re: [gdal-dev] Adding Vertex To Linestring in Existing shapefile(Python)
Hi Justin, ogr2ogr -segmentize max_dist:(starting with GDAL 1.6.0) maximum distance between 2 nodes. Used to create intermediate points . Mmight do what you want. Best regards, Eli On Wed, Jul 23, 2014 at 2:08 PM, Justin Williams jwill...@hotmail.com wrote: Hello All. I'm trying to add a vertex to a linestring inside of a shapefile and save the changes that I've made. So if I have a line that has 2 vertices. When I open the shapefile up again(in Global Mapper, QGIS,etc.) I have 3 vertices. How is this accomplished in gdal/ogr? ___ 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] GeoPDF translation
Hi rkologist, The driver page [0] and a wiki page [1] indicate that you can crop to the NEATLINE. Jim, if you are still following this thread, you can edit the wiki page with what you found works well for what you were doing too. GDAL has really made the USGS new generation topos more accessible. [0] http://www.gdal.org/frmt_pdf.html [1] http://trac.osgeo.org/gdal/wiki/USGS_PDF_Topo Best regards, Eli On Wed, Jul 23, 2014 at 6:26 PM, rkologist rcdem...@indiana.edu wrote: Can someone help me figure out where to insert the code to also have this crop to the neat line? I need to tile several maps together, and it would really help. Thanks -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-GeoPDF-translation-tp3742508p5152932.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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL 1.7.3 can't read tiff written by GDAL 1.11
Hi all, I've got some recent tiff data that can't be read by GDAL 1.7.3 (gdalinfo.exe has stopped working). It appears to work fine with GDAL 1.11. The output from GDAL 1.11 can't be read by GDAL 1.7.3 either. Hmm, oddly it seems to work with GDAL 1.6. I have an older MapServer and GDAL that I'd like to use with new data without updating MapServer and GDAL so my goal is find a way to use or alter the data so it is usable by GDAL 1.7.3. I also want to know if the data is valid and complies with the the geotif specification. This is on Windows 7 and OSGeo4W although I also had some similar issues on Ubuntu 10.04. Below are GDAL 1.11 version, gdalinfo with debug, listgeo, and finally gdal_translate output that can't be read by GDAL 1.7.3 (attached). There are messages about GTIFF: converting geokey to meters to fix bug in old libgeotiff and TIFFReadDirectory: Warning, Unknown field with tag 2457 (0x999) encountered. Further below the GDAL1.11 information, is GDAL 1.7.3 showing that it can't be read and the error output. Do 06S08W19_gdal1_11_ouput2.tif and 06S08W19.tif conform to the geotif specification and contain valid data? Any suggestions on how to keep using my older install without updating? Best regards, Eli gdalinfo --version GDAL 1.11.0, released 2014/04/16 gdalinfo 06S08W19.tif --debug on GDAL: GDALOpen(06S08W19.tif, this=027C3F20) succeeds as GTiff. Driver: GTiff/GeoTIFF GDAL: GDALDefaultOverviews::OverviewScan() Files: 06S08W19.tif 06S08W19.tfw Size is 3314, 5508 GTIFF: converting geokey to meters to fix bug in old libgeotiff GTIFF: converting geokey to meters to fix bug in old libgeotiff Coordinate System is: PROJCS[NAD_1983_2011_StatePlane_Oregon_North_FIPS_3601_Ft_Intl, GEOGCS[GCS_NAD_1983_2011, DATUM[NAD_1983_2011, SPHEROID[GRS_1980,6378137,298.257222101]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,44.34], PARAMETER[standard_parallel_2,46], PARAMETER[latitude_of_origin,43.66], PARAMETER[central_meridian,-120.5], PARAMETER[false_easting,8202099.737532808], PARAMETER[false_northing,0], UNIT[foot,0.3048, AUTHORITY[EPSG,9002]]] Origin = (7367100.000,520508.000) Pixel Size = (1.000,-1.000) Metadata: AREA_OR_POINT=Area TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) TIFFTAG_XRESOLUTION=200 TIFFTAG_YRESOLUTION=200 Image Structure Metadata: INTERLEAVE=PIXEL OGRCT: PROJ = 4.8.0 features enabled OGRCT: Source: +proj=lcc +lat_1=44.34 +lat_2=46 +lat_0=43.66 +lon_0=-120.5 +x_0=250 +y_0=0 +ellps=GRS80 +units=ft +no_defs OGRCT: Target: +proj=longlat +ellps=GRS80 +no_defs Corner Coordinates: Upper Left ( 7367100.000, 520508.000) (123d43'54.49W, 45d 2'54.88N) Lower Left ( 7367100.000, 515000.000) (123d43'51.43W, 45d 2' 0.54N) Upper Right ( 7370414.000, 520508.000) (123d43' 8.37W, 45d 2'56.19N) Lower Right ( 7370414.000, 515000.000) (123d43' 5.31W, 45d 2' 1.84N) Center ( 7368757.000, 517754.000) (123d43'29.90W, 45d 2'28.36N) Band 1 Block=256x256 Type=Byte, ColorInterp=Red Band 2 Block=256x256 Type=Byte, ColorInterp=Green Band 3 Block=256x256 Type=Byte, ColorInterp=Blue GDAL: GDALClose(06S08W19.tif, this=027C3F20) listgeo 06S08W19.tif TIFFReadDirectory: Warning, Unknown field with tag 2457 (0x999) encountered. Geotiff_Information: Version: 1 Key_Revision: 1.0 Tagged_Information: ModelTiepointTag (2,3): 000 7367100 520508 0 ModelPixelScaleTag (1,3): 110 End_Of_Tags. Keyed_Information: GTModelTypeGeoKey (Short,1): ModelTypeProjected GTRasterTypeGeoKey (Short,1): RasterPixelIsArea GTCitationGeoKey (Ascii,67): PCS Name = NAD_1983_2011_StatePlane_Oregon_N orth_FIPS_3601_Ft_Intl GeographicTypeGeoKey (Short,1): User-Defined GeogCitationGeoKey (Ascii,92): GCS Name = GCS_NAD_1983_2011 Datum = NAD_1 983_2011 Ellipsoid = GRS_1980 Primem = Greenwich GeogGeodeticDatumGeoKey (Short,1): User-Defined GeogAngularUnitsGeoKey (Short,1): Angular_Degree GeogEllipsoidGeoKey (Short,1): User-Defined GeogSemiMajorAxisGeoKey (Double,1): 6378137 GeogInvFlatteningGeoKey (Double,1): 298.257222101 GeogPrimeMeridianLongGeoKey (Double,1): 0 Unknown-3059 (Short,1): Unknown-1 ProjectedCSTypeGeoKey (Short,1): User-Defined ProjectionGeoKey (Short,1): User-Defined ProjCoordTransGeoKey (Short,1): CT_LambertConfConic_2SP ProjLinearUnitsGeoKey (Short,1): Linear_Foot ProjStdParallel1GeoKey (Double,1): 44.3 ProjStdParallel2GeoKey (Double,1): 46 ProjFalseOriginLongGeoKey (Double,1): -120.5 ProjFalseOriginLatGeoKey (Double,1): 43.7 ProjFalseOriginEastingGeoKey (Double,1):
Re: [gdal-dev] GDAL 1.7.3 can't read tiff written by GDAL 1.11
On Mon, Jul 21, 2014 at 1:46 PM, Even Rouault even.roua...@mines-paris.org wrote: Le lundi 21 juillet 2014 22:18:27, Eli Adam a écrit : Hi all, I've got some recent tiff data that can't be read by GDAL 1.7.3 (gdalinfo.exe has stopped working). It appears to work fine with GDAL 1.11. The output from GDAL 1.11 can't be read by GDAL 1.7.3 either. Hmm, oddly it seems to work with GDAL 1.6. I have an older MapServer and GDAL that I'd like to use with new data without updating MapServer and GDAL so my goal is find a way to use or alter the data so it is usable by GDAL 1.7.3. I also want to know if the data is valid and complies with the the geotif specification. Looks reasonable at first sight This is on Windows 7 and OSGeo4W although I also had some similar issues on Ubuntu 10.04. Below are GDAL 1.11 version, gdalinfo with debug, listgeo, and finally gdal_translate output that can't be read by GDAL 1.7.3 (attached). There are messages about GTIFF: converting geokey to meters to fix bug in old libgeotiff Yes, tricky issue with non-meter linear unit. See ticket https://trac.osgeo.org/gdal/ticket/3901 to get heavily confused. I read that and am somewhat confused :) but have a basic understanding of it as well now. I tried gdal_translate -projwin 7367110 520505 7367120 520495 06S08W19.tif 06S08W19_gdal1_11_ouput3.tif --config GTIFF_LINEAR_UNITS BROKEN to try and make a broken tiff to see if it would work. GDAL 1.7.3 can't read the output of that either. Related to that, I guess your listgeo is from libgeotiff 1.3 or older since it should display ProjFalseEastingGeoKey: 250.00 m normally Using the OSGeo4W installer libgeotiff appears to be 1.3.0-3 (is there a command line option to determine libgeotiff or libtiff version?). I just looked these up on EPSG and now my basic understanding of ticket 3901 is faltering. http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::6558entity=urn:ogc:def:crs:EPSG::6559reportDetail=longstyle=urn:uuid:report-style:default-with-urnstyle_name=OGP%20Default%20With%20Urntitle=Oregon_foot_meter Is it incorrect to report ProjFalseOriginEastingGeoKey (Double,1): 8202099.73753281 with ProjLinearUnitsGeoKey (Short,1): Linear_Foot? and TIFFReadDirectory: Warning, Unknown field with tag 2457 (0x999) encountered. Cannot find its definition in the TIFF tag catalog, but shouldn't cause issues. This will be ignored Further below the GDAL1.11 information, is GDAL 1.7.3 showing that it can't be read and the error output. Do 06S08W19_gdal1_11_ouput2.tif and 06S08W19.tif conform to the geotif specification and contain valid data? Any suggestions on how to keep using my older install without updating? I managed to read your attachef file with latest state of 1.7 branch (1.7.3 with a few additional fixes) on Linux, and cannot see anything in the log between this and 1.7.3 that could explain the issue. However, as more or less expected, the georeferencing is not read correctly (since #3901 was fixed in 1.8) and the false easting value is multiplied by 1. / 0.3048. Would different versions of libgeotiff explain it working (with incorrect georeferencing?) for you and erroring out for me? You will never (or with much difficulty) manage to make it work with non-meter linear units in old GDAL releases. I'd encourage you warping it into a UTM projection for example. Thanks for the suggestion. I'll pursue this and it sounds like this will work for me. Best regards, Eli Best regards, 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] GDAL 1.7.3 can't read tiff written by GDAL 1.11
I just looked these up on EPSG and now my basic understanding of ticket 3901 is faltering. http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:c rs:EPSG::6558entity=urn:ogc:def:crs:EPSG::6559reportDetail=longstyle=urn :uuid:report-style:default-with-urnstyle_name=OGP%20Default%20With%20Urnt itle=Oregon_foot_meter Is it incorrect to report ProjFalseOriginEastingGeoKey (Double,1): 8202099.73753281 with ProjLinearUnitsGeoKey (Short,1): Linear_Foot? It is correct, but the listgeo output also lists afterwards something like : Projection Method: CT_LambertConfConic_2SP ProjFalseOriginLatGeoKey: 43.67 ( 43d40' 0.00N) ProjFalseOriginLongGeoKey: -120.50 (120d30' 0.00W) ProjStdParallel1GeoKey: 44.33 ( 44d20' 0.00N) ProjStdParallel2GeoKey: 46.00 ( 46d 0' 0.00N) ProjFalseEastingGeoKey: 250.00 m ProjFalseNorthingGeoKey: 0.00 m Projection Linear Units: 9002/foot (0.304800m) where ProjFalseEastingGeoKey is normalized in meters. I missed this on initial reading. Thanks for pointing it out and letting me learn some more. I managed to read your attachef file with latest state of 1.7 branch (1.7.3 with a few additional fixes) on Linux, and cannot see anything in the log between this and 1.7.3 that could explain the issue. However, as more or less expected, the georeferencing is not read correctly (since #3901 was fixed in 1.8) and the false easting value is multiplied by 1. / 0.3048. Would different versions of libgeotiff explain it working (with incorrect georeferencing?) for you and erroring out for me? No idea why it crashes on osgeo4w. Well, I somehow remember that there have been ABI changes in libgeotiff between versions, but if that was the case of a mismatch between actual libgeotiff ABI and the one expected by the GDAL build, then it would likely crash on most geotiff files, and not that one only. Does it crash only on that geotiff ? Anyway that's an old version, and you cannot undo the past, just try to make the future better ;-) GDAL 1.7.3 in OSGeo4W only crashes on this collection of geotiffs and works fine on other files. Thanks for spending time on what is probably perceived by you as an ancient version and probably of little interest to you. You are always making the future better; thanks for all your work in that regard. Thanks also for going out of your way to help all users at all levels. I've found the GDAL-dev list to be kind and welcoming to all who write. Sincerely, Eli 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] gdal installation, geopdf not recognized
Hi Jian, On Mon, Jul 14, 2014 at 7:52 AM, Liu, Jian j...@eris.ca wrote: Hello, I have been trying to install GDAL to convert USGS GeoPdf. Googling gave me a couple of links for quick installation for windows. http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries lists some additional options. I often use http://www.gisinternals.com/sdk/ from Tamas. http://trac.osgeo.org/osgeo4w/wiki · http://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal (GDAL‑1.11.0.win32‑py2.7.exe) I have 32 bit machine, windows 7 and python 2.7. There was a side-by-side configuration error, so I had to get that .dll, and I tried a couple of times. The installation seemed successful, however, I got error when reading a geopdf: ERROR 4: `C:\TestFolder\WI_Madison_West_20100723_TM_geo.pdf' not recognized as a supported file format. I got this error from OSGeo4W too. The last two lines of this page, http://trac.osgeo.org/osgeo4w/ticket/408, lists the mailing list and ticket tracker. You can ask or report this error there. Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 If you list a link to the file, it is easier for people to test. I found, this, ims.er.usgs.gov/gda_services/download?item_id=5954807 for testing. I tested with about a four month old download from http://www.gisinternals.com/sdk/ and it worked showing this, gdalinfo WI_Madison_West_20130722_TM_geo.pdf Driver: PDF/Geospatial PDF Files: WI_Madison_West_20130722_TM_geo.pdf Size is 13656, 17407 Coordinate System is: PROJCS[UTM Zone 16, Northern Hemisphere, ... ... Corner Coordinates: Upper Left ( 294830.111, 4779306.587) ( 89d31'22.05W, 43d 8'19.31N) Lower Left ( 294317.106, 4761635.933) ( 89d31'21.23W, 42d58'46.52N) Upper Right ( 308692.951, 4778904.128) ( 89d21' 8.42W, 43d 8'19.34N) Lower Right ( 308179.946, 4761233.474) ( 89d21' 9.19W, 42d58'46.51N) Center ( 301505.029, 4770270.031) ( 89d26'15.22W, 43d 3'33.04N) Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=1024x1024 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=1024x1024 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=1024x1024 Type=Byte, ColorInterp=Alpha So the file is fine but something appears to be wrong with the OSGeo4W geopdf support. The binaries at http://www.gisinternals.com/sdk/ from Tamas seem to properly support geopdf. Best Regards, Eli Even though pdf is listed with gdalinfo –formats: PDF (rw): Geospatial PDF Anybody could point me to a solution to this? It’s much appreciated. (I saw a previous post about cleaning before a new installation. That could be my problem too. But not sure how to do this with windows. Any clue would be helpful, thanks!) Regards, Jian ___ 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] gdal installation, geopdf not recognized
On Mon, Jul 14, 2014 at 11:17 AM, Jürgen E. j...@norbit.de wrote: Hi Eli, On Mon, 14. Jul 2014 at 10:40:08 -0700, Eli Adam wrote: I got this error from OSGeo4W too. The last two lines of this page, http://trac.osgeo.org/osgeo4w/ticket/408, lists the mailing list and ticket tracker. You can ask or report this error there. Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 I can't reproduce that. WI_Madison_West_20130722_TM_geo.pdf works fine with both the 32 and the 64bit build in OSGeo4W (using gdal-1.11.0-2). I tried gdalinfo --debug on but that did not provide additional information. gdalinfo --version reports GDAL 1.11.0, released 2014/04/16 Before I try updating OSGeo4W and seeing if anything changes, is there anything else to try to find the source of the error? My install is the result of an advanced install about three months ago and probably updated about a month or two ago. Thanks, Eli Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ 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] gdal installation, geopdf not recognized
On Mon, Jul 14, 2014 at 12:35 PM, Jürgen E. j...@norbit.de wrote: Hi Eli, On Mon, 14. Jul 2014 at 10:40:08 -0700, Eli Adam wrote: Searching through trac for OSGeo4W, I found this which seems like it might be similar, http://trac.osgeo.org/osgeo4w/ticket/408 I can't reproduce that. WI_Madison_West_20130722_TM_geo.pdf works fine with both the 32 and the 64bit build in OSGeo4W (using gdal-1.11.0-2). Before I try updating OSGeo4W and seeing if anything changes, is there anything else to try to find the source of the error? My install is the result of an advanced install about three months ago and probably updated about a month or two ago. Ok, that's explains it. #408 tries to explain that 1.11.0-2 is from 9 days ago and introduces pdf read support - earlier didn't have it. More carefully reading, I now see that the fix was 9 days ago. I updated and as expected OSGeo4W reads geopdf fine. Thanks, Eli Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ 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] What happens by default when writing RGBA into jpeg?
On Tue, Jun 10, 2014 at 6:28 AM, Even Rouault even.roua...@mines-paris.org wrote: Thanks, that makes sense. However, the result is somehow surprising and I guess that in most cases unusable for the user. I wonder if it would be good to print something like WARNING. Encountered 4 source bands, assuming CMYC color space. Behaviour is not very easy to understand by reading the driver page http://www.gdal.org/frmt_jpeg.html When I try to look at the situation as a QGIS user sees it, it feels like there is a bug somewhere but I can't say exactly where. However, I do not believe that any average QGIS user can have success with converting their RGBA tiffs into jpeg format even it is possible by editing gdal_translate command manually. Agreed that the current behaviour is confusing. A check could be done on the color interpretation of the source bands to check if it is C,M,Y,K when a 4 band dataset is provided. If not, then output the warning (and possibly error out if -strict is specified) Some GDAL warning also give helpful hints. Could this warning suggest something like, RGBA files can be converted to JPEG by adding -b 1 -b 2 -b 3? Eli ___ 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] problem with gdal_translate jp2 file from the usgs (linux)
Kasper, On Thu, Apr 24, 2014 at 2:32 PM, Even Rouault even.roua...@mines-paris.org wrote: Le jeudi 24 avril 2014 23:29:03, Kasper van Wijk a écrit : thank you, Even, for the fast reply. I am a beginner at GDAL and installed the gdal suite with standard apt-get and yum, respectively. Can you point me to a place where I can read how to compile GDAL against one of the other JPEG2000 libraries, as you say? Compiling is a great option and might be the best. You might also want to check which drivers are in Ubuntu GIS and Enterprise Linux GIS which might be easier than compiling. They are often more recent and with more features than the standard repos. https://wiki.ubuntu.com/UbuntuGIS http://wiki.osgeo.org/wiki/Enterprise_Linux_GIS Best regards, Eli You will find various resources at http://trac.osgeo.org/gdal/wiki/BuildHints Most interesting links for your use case : * http://trac.osgeo.org/gdal/wiki/DownloadSource * http://trac.osgeo.org/gdal/wiki/BuildingOnUnix * http://trac.osgeo.org/gdal/wiki/ECW : if you want to compile against ECW SDK * http://gdal.org/frmt_jp2openjpeg.html : if you want to compile against OpenJPEG v2 Thanks again, Kasper On 25 April 2014 09:25, Even Rouault even.roua...@mines-paris.org wrote: Le jeudi 24 avril 2014 23:17:29, Kasper van Wijk a écrit : dear all, I am downloading jp2 data from the usgs national map. To plot this in cartopy, I need to transform to something else, such as geotiff. However, using gdal_translate I get a warning copied below, and the output is a grainy bw version of the image. I have checked my results under linux both fedora core 20 and ubuntu 12.04 versions with GDAL 1.7.3, released 2010/11/10 gdal_translate m_3810623_ne_13_1_20110921_20111031.jp2 test.tiff -of GTiff warning: not enough tile data (2 bytes) Apparently your GDAL build uses libjasper as the jpeg2000 library. Jasper doesn't work very well unfortunately with some real world images. You might want to compile GDAL against one of the other JPEG2000 libraries that are supported : see http://gdal.org/formats_list.html -- Geospatial professional services http://even.rouault.free.fr/services.html -- 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Using/citing GDAL documentation
On Fri, Oct 18, 2013 at 6:13 PM, Jonathan Greenberg j...@illinois.edu wrote: GDALers: I'm working with a colleague on a new set of R wrappers for GDAL, and we are at the point where we are starting to document the functions. Our R interface is designed to be VERY close to the GDAL command line utilities (we use the same parameter names, for instance), so I was wondering if it would be ok to use almost word-for-word the GDAL documentation of each of the parameters in our package's man files (this would save us an inordinate amount of time paraphrasing the docs for all of those functions). If this is ok, how should I cite the documentation properly? I can't answer about reuse of the documentation, but citation is probably covered here, http://trac.osgeo.org/gdal/wiki/FAQGeneral#HowdoIciteGDAL Hopefully someone else will more directly answer your questions (my uninformed opinion is that reuse is probably fine). Best Regards, Eli Cheers! Incidentally, the package is up on R-forge: https://r-forge.r-project.org/projects/gdalutils/ --j -- Jonathan A. Greenberg, PhD Assistant Professor Global Environmental Analysis and Remote Sensing (GEARS) Laboratory Department of Geography and Geographic Information Science University of Illinois at Urbana-Champaign 259 Computing Applications Building, MC-150 605 East Springfield Avenue Champaign, IL 61820-6371 Phone: 217-300-1924 http://www.geog.illinois.edu/~jgrn/ AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007 ___ 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] In which version utilities have appeared?
On Fri, Nov 8, 2013 at 10:34 AM, Even Rouault even.roua...@mines-paris.org wrote: Le vendredi 08 novembre 2013 19:30:34, Jukka Rahkonen a écrit : Even Rouault even.rouault at mines-paris.org writes: Le vendredi 08 novembre 2013 19:19:35, Jukka Rahkonen a écrit : Hi, Is there a list about the minimum GDAL version for each of the GDAL tools in http://www.gdal.org/gdal_utilities.html? There are not that many utilities, however, many of the utilities have all kinds of flags and features which started at various versions. Looking for starting with gdal on http://gdal.org/ogr2ogr.html gives a hint at that complexity. starting with or GDAL on http://gdal.org/gdal_translate.html And if there are changes in formats (or proj4) that interact with these flags... Coherent presentation would require a huge table or chart and maybe still be confusing. $.02, Eli Not directly. A solution would be to download the *doc packages on http://download.osgeo.org/gdal/ and look at the differences Oh dear. And if I bother to do that what might be a good place to share the results? Wiki perhaps? I am writing short tutorials sometimes and it is essential to mension the versions because there are old GDAL versions in the wild and included in other programs. Well, I admire your energy. Why not being lazy and telling that your tutorial applies to GDAL 1.10 or above, and if people are using older versions some things might not apply. -Jukka- ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [EXTERNAL] /vsicurl/ and gz files
There is also more info on the wiki, http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip Best Regards, Eli On Thu, Oct 10, 2013 at 11:56 AM, Smith, Michael ERDC-RDE-CRREL-NH michael.sm...@erdc.dren.mil wrote: Jose, You can use /vsigzip/ with /vsicurl Try gdalinfo /vsigzip/vsicurl/http://www.globalbedo.org/GlobAlbedo29/tiles/2004/h17v04/GlobAlbedo.2004001.h17v04.nc.gz Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers From: Jose Gomez-Dans jgomezd...@gmail.com Date: Thursday, October 10, 2013 2:33 PM To: gdal-dev gdal-dev@lists.osgeo.org Subject: [EXTERNAL] [gdal-dev] /vsicurl/ and gz files Resent-From: Michael Smith michael.sm...@usace.army.mil Hi, I was wondering if it's possible to use /vsitar/ to have a peek in .gz files, such as this one: http://www.globalbedo.org/GlobAlbedo29/tiles/2004/h17v04/GlobAlbedo.2004001.h17v04.nc.gz The file is a NetCDF, with 20 different layers. I was hoping to be able to read the file in using /vsitar/ (actually, combining /vsicurl/ and /vsitar/), but using e.g. /vsitar/GlobAlbedo.2004001.h17v04.nc.gz I get: $ gdalinfo /vsitar/GlobAlbedo.2004129.h17v04.nc.gz ERROR 4: `/vsitar/GlobAlbedo.2004129.h17v04.nc.gz' does not exist in the file system, and is not recognised as a supported dataset name. gdalinfo failed - unable to open '/vsitar/GlobAlbedo.2004129.h17v04.nc.gz'. GDAL: In GDALDestroy - unloading GDAL shared library. I also get failures when I try to open remote sample netcdf files using /vsicurl/: $ gdalinfo /vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc VSICURL: GetFileSize(http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc)=2949152 response_code=200 VSICURL: GetFileList(/vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples) VSICURL: Downloading 0-16383 (http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc)... VSICURL: Got reponse_code=206 GDAL_netCDF: = calling nc_open( /vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc ) ERROR 1: netcdf error #-33 : NetCDF: Not a valid ID . at (netcdfdataset.cpp,~netCDFDataset,1446) GDAL: GDALClose(/vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc, this=0x1e2ca40) gdalinfo failed - unable to open '/vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc'. GDAL: In GDALDestroy - unloading GDAL shared library. Questions: 1.- Do gzipped files work with /vsitar/? 2.- Are remote/compressed netcdf files useable with GDAL? 3.- How do you select a particular layer if the answer to (2) is yes? Thanks for your time! Jose ___ 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] concatenated VRT file
On Tue, Aug 6, 2013 at 2:21 AM, Jan Hartmann j.l.h.hartm...@uva.nl wrote: ** Not sure if this is possible, but perhaps someone here knows a trick. I use a VRT file as an index to a large set of detailed, tiled scans of the Netherlands, built with gdalbuildvrt. I recently discovered how to transform this map on the fly, so that it exactly aligns to older maps in different coordinate systems. It's just a matter of adapting the geotransform item in the VRT file. I'm not sure if this will work for what you are doing, but I change the projection of VRT files with gdalwarp: gdalwarp -of VRT -t_srs +proj=omerc +lat_0=44.75 +lonc=-124.05 +alpha=5 +k=1 +x_0=134743.33241 +y_0=369139.02771 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048 +no_defs +wktext infile.vrt outfile.vrt Eli So I can copy the VRT file for every old map, and adapt the geotransform in each of them. This means that all VRT files will be identical, except for the geotransform line. The VRT files are quite large, because they cover lots of tiles. Can anyone here think of a method to do this with one central VRT file, in which only the geotransform line is plugged that is required for the particular old map? Something like a symbolic link to concatenate the variable and stable parts of the VRT file? Jan ___ 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] Working with NTF files
No (except that I left this option as the final attempt of many tests -- working with some 1GB images here, so it took me hours... :D). Your confirmation, though, is highly useful! Sometimes to avoid materializing large intermediate datasets on disk, a VRT can be used. I'm not sure if this would be useful in your case. On the GDAL side we often have special info in trac wiki pages under the BuildHints page, but in this case the issues are more usage rather than building so there is no obvious place for user contributions. The format pages for NITF do have quite a bit of info. It is (I think) the only driver with an advanced page. However, there are many kinds of NITF files and thus usage patterns that are an issue so it isn't clear how to handle that in the user docs. I and others have put GDAL usage notes here, http://trac.osgeo.org/gdal/wiki/CodeSnippets Best Regards, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Clipping imprecision with gdal_translate
gdalwarp does have -tap which may be of some use. Quoting the doc page: -tap:(GDAL = 1.8.0) (target aligned pixels) align the coordinates of the extent of the output file to the values of the -tr, such that the aligned extent includes the minimum extent. Best Regards, Eli On Tue, Jun 4, 2013 at 12:35 AM, Ari Jolma ari.jo...@gmail.com wrote: JM, Looks to me that GDAL has clipped to the nearest pixel boundaries and not to the window you have provided. This is probably a feature. Maybe gdalwarp would do the kind of resampling you wish, but I'm not sure. Regards, Ari On 06/03/2013 03:37 PM, JM wrote: Hello List. At first i wanna thanks for the great work you are doing with the gdal library. It is a source of great tools and opportunities for spatial issues which whom i involed in. Among others i am using the commandline tool gdal_translate for clipping raster files via the following example command: gdal_translate -projwin 13.664938 53.202428 13.834784 53.117686 source.tif target.tif The source tif is already georeferenced (EPSG:4326). I would now assume that the boundingbox of the following GTiff is somethink like this: Lower Left: 13.664938 53.117686 Upper Right: 13.834784 53.202428 Instead it is something like this (the full gdalinfo dialog you can see in the attach to this mail): Lower Left: 13.610463 53.1000244672 Upper Right: 13.8333191458 53.2000151873 So there is a small imprecision in the clipping result. My question is now if this imprecision is normal (maybe a result of rounding operations within the clipping process) or if i do something wrong (do i miss something in my command). I am using libgdal1 version 1.9.0-3.1ubunut1. Looking forward to hearing from you. Kind regards, JM ___ 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] select shapes in a folder by geometry type
If you are using a recent version can you ignore geometry type and use the -dim 2 switch? -dim val:(starting with GDAL 1.10) Force the coordinate dimension to val (valid values are 2 or 3). This affects both the layer geometry type, and feature geometries. Best Regards, Eli On Fri, May 24, 2013 at 9:23 AM, Pedro Costa pedrocostaa...@sapo.pt wrote: Hi guys, I'm trying to make a script that converts 3d shapefiles to 2d. I'm using the loop 'for...do'' and this command: 'ogr2ogr -f ESRI Shapefile -nlt POINT 2d_points/$shp $shp' My problem is that i don't know how to select only shapefiles of points, and next only polygons, and next only lines to put the right geometry in the command. For example, i have tried the '-where OGR_GEOMETRY='Point'' like that: ogr2ogr -where OGR_GEOMETRY='Point' -f ESRI Shapefile -nlt POLYGON 2d_poligonos/$shp $shp But don't work because ogr converts shapefiles of polygons and lines into points! Can anyone tell me how i can select only shapefiles of points in a folder with many shapefiles of many geometry types? Thanks ___ 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] select shapes in a folder by geometry type
[1] ogr2ogr -f ESRI Shapefile -dim 2 pontos_2d.shp ocup_ilegal.shp Yes just like this. With this command don't work. I'm using 1.9 version but the '-dim' option don't show up if i type 'ogr2ogr --long-usage'. It is only in GDAL 1.10+ so it will not work in 1.9. Eli Em 24-05-2013 17:44, Eli Adam escreveu: If you are using a recent version can you ignore geometry type and use the -dim 2 switch? -dim val:(starting with GDAL 1.10) Force the coordinate dimension to val (valid values are 2 or 3). This affects both the layer geometry type, and feature geometries. Best Regards, Eli On Fri, May 24, 2013 at 9:23 AM, Pedro Costa pedrocostaa...@sapo.pt wrote: Hi guys, I'm trying to make a script that converts 3d shapefiles to 2d. I'm using the loop 'for...do'' and this command: 'ogr2ogr -f ESRI Shapefile -nlt POINT 2d_points/$shp $shp' My problem is that i don't know how to select only shapefiles of points, and next only polygons, and next only lines to put the right geometry in the command. For example, i have tried the '-where OGR_GEOMETRY='Point'' like that: ogr2ogr -where OGR_GEOMETRY='Point' -f ESRI Shapefile -nlt POLYGON 2d_poligonos/$shp $shp But don't work because ogr converts shapefiles of polygons and lines into points! Can anyone tell me how i can select only shapefiles of points in a folder with many shapefiles of many geometry types? Thanks ___ 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] Help about GDAL
Edison, I've had similar problems (although for different reasons I think). The suggestions at the end of this are similar to what I've done to make it work for me, http://lists.osgeo.org/pipermail/gdal-dev/2009-March/020132.html Sudo ldconfig might help too. Regards, Eli On May 10, 2013 8:38 PM, edison Qian edison90...@gmail.com wrote: Dear List: i have met an error about GDAL that when a cpp file including GDAL library is coded, i compile this cpp file with following command in ubuntu bash: $g++ gdal_linux.cpp -I /usr/local/include/ -L /usr/local/lib/ -lgdal -o aaa it succeeds! however, when i run file aaa, an error appears: error while loading shared libraries: libgdal.so.1: cannot open shared object file: No such file or directory which is similar to the one Wesley got: http://lists.osgeo.org/pipermail/gdal-dev/2009-March/020128.html i wonder whether this problem has been solved or not because i've not seen any solutions to it. Any help would be greatly appreciated. Kind regards, Edison ___ 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] Merge overviews from multiple files
On Fri, Apr 19, 2013 at 9:47 PM, ryagz raghaven...@vizexperts.com wrote: Hi, I have downloaded some raster data which has given me overview levels as different tiff files, how can i merge them into a single tiff file. so that when i load that file with gdal proper overviews are picked. If your files are named file.tif, file.tif.ovr, file.tif.ovr.ovr, etc I think that GDAL will automatically read the overviews. gdalinfo file.tif will show if GDAL reports the presence of the overviews. A VRT could be used to combine the various files then gdal_translate that. gdal_translate with COPY_SRC_OVERVIEWS=YES could create a single tif with the overviews (more details, http://www.gdal.org/frmt_gtiff.html). I'm not sure if COPY_SRC_OVERVIEWS will work on external overviews. Eli Ryagz -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Merge-overviews-from-multiple-files-tp5048389.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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Neatline for USGS PDF maps
I found this in drafts and it appears I failed to send it. Sorry for
delay. Sent partly for the list archives at this point.
On Sat, Jan 19, 2013 at 8:14 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Looking more closely at those files, I see that there are various
registration blocks. The algorithm up to now was to select the
registration block whose neatline covered the most area in terms of
pixels. In the case of
OR_Newport_North_20110824_TM_geo.pdf, those blocks are :
UTM Grid and Projection
Orthoimage
Map Layers
Adjoining Quadrangles Diagram
The number and names of blocks may change, but in all USGS topo PDFs
samples I've tried, the Map Layers is always present and seems to the
one that lead to the best results, so I've just pushed a change to select
it when it is found.
--config GDAL_PDF_NEATLINE is very helpful. Did you find the
registration name blocks with one of the supporting PDF libraries? Is
it possible to find these multiple registration name blocks from gdal?
(I tried: gdalinfo --debug on without success.)
Thanks for the many recent improvements for the USGS topo PDFs.
--config GDAL_PDF_RENDERING_OPTIONS is very useful.
You can use the following Python script to automate fetching the neatline
and launching gdalwarp to use it :
from osgeo import gdal
import os
import sys
ds = gdal.Open(sys.argv[1])
neatline_wkt = ds.GetMetadataItem(NEATLINE)
ds = None
f = open('cutline.csv', 'wt')
f.write('id,WKT\n')
f.write('1,%s\n' % neatline_wkt)
f.close()
os.system('gdalwarp %s %s.tif ' % (sys.argv[1], sys.argv[1]) +
'-crop_to_cutline -cutline cutline.csv -overwrite')
This is great. I've added it to the wiki,
http://trac.osgeo.org/gdal/wiki/USGS_PDF_Topo
If you're interested in only the raster part, let's imagine that the above
script is called cutline.py, you can try the following :
export GDAL_PDF_RENDERING_OPTIONS=RASTER
(or set GDAL_PDF_RENDERING_OPTIONS=RASTER on windows)
python cutline.py your.pdf
nearblack your.pdf -o your_rgba.pdf -of GTiff -setalpha -color 0,0,0 \
-color 255,255,255
I interpreted the above as:
nearblack your.tif -o your_rgba.tif -of GTiff -setalpha -color 0,0,0
-color 255,255,255
Where your.tif is the output from cutline.py and your_rgba.tif is the
output from nearblack.
Thanks, Eli
Best regards,
Even
___
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] TIFFMergeFieldInfo error when adding overviews to large tiff
Even, Thanks for checking into this and the ideas. Eli On Tue, Apr 16, 2013 at 10:18 AM, Even Rouault even.roua...@mines-paris.org wrote: Le lundi 15 avril 2013 23:47:33, Eli Adam a écrit : Hi all, I'm adding internal overviews to a ~20G tiff file and I get this error (1000+ times): gdaladdo topo_mosaic_4326.tif 2 4 8 16 32 64 128 256 512 1024 --config COMPRESS_OVERVIEW PACKBITS ERROR 1: topo_mosaic_4326.tif:Failed to allocate memory for for fields array (1410046 elements of 16 bytes each) gdaladdo still completes and the file seems to work fine. What does that error mean? Does it impact the output file or overviews? Is there a different way I should approach this? Are there any general rules for which compression to select? I've found JPEG-In-TIFF, using PHOTOMETRIC=YCBCR to work very well for RGB, but otherwise I'm unsure of the best compression for the type of raster (in this case single band, byte, colormap). That's interesting. I've tried to reproduce your setup with an artificial blank input file of the same dimensions and here's what I get (after several hours): $ gdaladdo topo_mosaic_4326.tif 2 4 8 16 32 64 128 256 512 1024 --config COMPRESS_OVERVIEW PACKBITS 0...10...20...30...40...50...60...70...80...90...100 - done. Current VSI memory usage: 0 bytes Maximum VSI memory usage: 2361761086 bytes Number of calls to VSIMalloc() : 43981823 Number of calls to VSICalloc() : 1259 Number of calls to VSIRealloc() : 17378556 Number of calls to VSIFree(): 43983082 VSIMalloc + VSICalloc - VSIFree : 0 The interesting part is the memory usage report. It is based on an instrumented version of GDAL that instruments each memory allocation routine. This is with the internal version of libtiff that redirects the TIFF memory allocation routines to the GDAL ones. So apparently there wouldn't be a memory leak (some valgrind'ing should be done on a smaller file to confirm), but a maximum memory usage of 2.3 GB ! No wonder why it fails on a Windows 32 bit (my test was done a Linux 64bit). I'm not sure why such a high memory use occurs. Some investigation should be done. As far as the error message you've seen, I wouldn't swear that there's not some pixel corruption in the result you get... As a potential track for a workaround (completely untested), perhaps you could try to do : $ gdaladdo topo_mosaic_4326.tif 2 --config COMPRESS_OVERVIEW PACKBITS $ gdaladdo topo_mosaic_4326.tif 4 --config COMPRESS_OVERVIEW PACKBITS $ gdaladdo topo_mosaic_4326.tif 8 --config COMPRESS_OVERVIEW PACKBITS $ gdaladdo topo_mosaic_4326.tif 16 --config COMPRESS_OVERVIEW PACKBITS etc.. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] TIFFMergeFieldInfo error when adding overviews to large tiff
On Tue, Apr 16, 2013 at 2:11 PM, Even Rouault even.roua...@mines-paris.org wrote: I've investigated a bit and I've discovered that while computing overviews, libtiff constantly switches from TIFF directories (main image, first overview,second overview, etc...). While doing this, it calls each time client code to install its own TIFF tags (libgeotiff for the geotiff tags, GDAL for the GDAL specific TIFF tags), but doesn't reset its array of existing tags. So each time the tags are added again and again, hence the huge memory allocation. Could you test the attached patch (assuming you build GDAL with internal libtiff) ? I can apply and test this on linux but don't know how to do it on windows. I usually use the nightly windows builds from Tamas. Should I test this on linux? It would be good if you could also open a ticket in Trac about that issue. I've opened a ticket, http://trac.osgeo.org/gdal/ticket/5054 Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] TIFFMergeFieldInfo error when adding overviews to large tiff
Hi all, I'm adding internal overviews to a ~20G tiff file and I get this error (1000+ times): gdaladdo topo_mosaic_4326.tif 2 4 8 16 32 64 128 256 512 1024 --config COMPRESS_OVERVIEW PACKBITS ERROR 1: topo_mosaic_4326.tif:Failed to allocate memory for for fields array (1410046 elements of 16 bytes each) gdaladdo still completes and the file seems to work fine. What does that error mean? Does it impact the output file or overviews? Is there a different way I should approach this? Are there any general rules for which compression to select? I've found JPEG-In-TIFF, using PHOTOMETRIC=YCBCR to work very well for RGB, but otherwise I'm unsure of the best compression for the type of raster (in this case single band, byte, colormap). I just checked my version and I am running 1.9.0 on a older modest XP laptop (I figured that I would have been running something more recent). I can try again with a nightly or compile on Ubuntu or use a computer with more resources (the process takes a long time to run, so reporting back on those will take some time). Here is information (I've omitted some previous mosaicing and reprojecting) of how I got to this point and some gdalinfo reports: gdal_translate mosaic_4326.vrt topo_mosaic_4326.tif -co COMPRESS=PACKBITS -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 400 gdaladdo topo_mosaic_4326.tif 2 4 8 16 32 64 128 256 512 1024 --config COMPRESS_OVERVIEW PACKBITS ERROR 1: topo_mosaic_4326.tif:Failed to allocate memory for for fields array (1410046 elements of 16 bytes each) original input files: gdalinfo ID_Cuddy_Mountain_20110715_TM_geo.tif Driver: GTiff/GeoTIFF Files: ID_Cuddy_Mountain_20110715_TM_geo.tif Size is 4880, 6845 Coordinate System is: PROJCS[NAD83 / UTM zone 11N, GEOGCS[NAD83, DATUM[North_American_Datum_1983, SPHEROID[GRS 1980,6378137,298.2572221010002, AUTHORITY[EPSG,7019]], AUTHORITY[EPSG,6269]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4269]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,-117], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,26911]] Origin = (509873.30982669181,4969095.03341848590) Pixel Size = (2.032010116947724,-2.032010116947745) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 509873.310, 4969095.033) (116d52'30.00W, 44d52'30.74N) Lower Left ( 509873.310, 4955185.924) (116d52'30.97W, 44d44'59.97N) Upper Right ( 519789.519, 4969095.033) (116d44'58.04W, 44d52'30.00N) Lower Right ( 519789.519, 4955185.924) (116d44'59.99W, 44d44'59.23N) Center ( 514831.415, 4962140.479) (116d48'44.75W, 44d48'45.05N) Band 1 Block=4880x1 Type=Byte, ColorInterp=Palette NoData Value=195 Color Table (RGB with 256 entries) 0: 0,0,0,255 1: 128,0,0,255 2: 0,128,0,255 3: 128,128,0,255 ... 254: 0,255,255,255 255: 255,255,255,255 final output file with overviews: gdalinfo -checksum topo_mosaic_4326.tif Driver: GTiff/GeoTIFF Files: topo_mosaic_4326.tif Size is 398449, 210532 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (-124.732439702451200,46.380533997595272) Pixel Size = (0.20993062915,-0.20993062915) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=PACKBITS INTERLEAVE=BAND Corner Coordinates: Upper Left (-124.7324397, 46.3805340) (124d43'56.78W, 46d22'49.92N) Lower Left (-124.7324397, 41.9608225) (124d43'56.78W, 41d57'38.96N) Upper Right (-116.3677748, 46.3805340) (116d22' 3.99W, 46d22'49.92N) Lower Right (-116.3677748, 41.9608225) (116d22' 3.99W, 41d57'38.96N) Center (-120.5501072, 44.1706782) (120d33' 0.39W, 44d10'14.44N) Band 1 Block=256x256 Type=Byte, ColorInterp=Palette Checksum=45365 NoData Value=195 Overviews: 199225x105266, 99613x52633, 49807x26317, 24904x13159, 12452x6580, 6 226x3290, 3113x1645, 1557x823, 779x412, 390x206 Overviews checksum: 27605, 16665, 58099, 63342, 4876, 64021, 44152, 14528, 574 63, 15006 Color Table (RGB with 256 entries) 0: 0,0,0,255 1: 128,0,0,255 2: 0,128,0,255 3: 128,128,0,255 ... 253: 255,0,255,255 254: 0,255,255,255 255: 255,255,255,255 Best Regards, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr convert e00 to shp
Murat, I was creating shp file using ogr2ogr as follows avcimport file.e00 coverage ogr2ogr -f ESRI Shapefile file.shp coverage This was worked well for old version of gdal I have installed gdal 1.9 then I have faced such a problem the ogr2ogr command create a directory and shp file located unter that directory. But old version of ogr2ogr was created files under the same directory where you work I think that ogr2ogr has (sometimes) created shapefiles in directories for a long time before 1.9. the old version of ogr2ogr creates file.shp file.shx file.dbf but new version create directory under working directory called file.shp instead of file.shp file and the shp files located under file.shp directory Please let me know what is differs this resuts. Regards Murat The shapefile driver page talks about this some, http://gdal.org/ogr/drv_shapefile.html I notice similar things (this is with PostGIS datasource). If the output shp file is the same name as input source then the shp is created in the specified directory. If it is a different name, then I get a directory. ogr2ogr V:\Data\E_addendum\Assessor\2012\nbhd\nbhd_codes_2012_postgis2.shp PG:host=123.12.12.12 user=username dbname=mydatabase password=mypassword taxlots2012_union_valid_nbhd_codes_v1 -a_srs EPSG:2913 creates a directory and then the shp (and the shp has the name of the original datasource), i.e. V:\Data\E_addendum\Assessor\2012\nbhd\nbhd_codes_2012_postgis2.shp\taxlots2012_union_valid_nbhd_codes_v1.dbf, .shp, etc ogr2ogr V:\Data\E_addendum\Assessor\2012\nbhd\taxlots2012_union_valid_nbhd_codes_v1.shp PG:host=123.12.12.12 user=username dbname=mydatabase_template password=mypassword taxlots2012_union_valid_nbhd_codes_v1 -a_srs EPSG:2913 creates the named shp in the directory. I have occasionally found this a minor annoyance. Is there a config or creation option to change this? A search of the email archives didn't turn anything up for me. Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutline layer for USGS GeoPDF maps
On Fri, Jan 18, 2013 at 2:53 PM, Even Rouault even.roua...@mines-paris.org wrote: Le vendredi 18 janvier 2013 23:43:39, Kris Andersen a écrit : I'm having trouble using the -crop_to_cutline option in gdalwarp to remove whitespace around USGS topo maps. These maps are in the GeoPDF format, and contain a NEATLINE metadata value that is suppose to provide the information to crop the image. I thought I could do this using the -cl flag, gdalwarp -crop_to_cutline -cl NEATLINE VA_Strasburg_20110524_TM_geo.pdf test.tiff but that didn't work. I still see lots of whitespace, and the image looks oddly skewed. See http://osgeo-org.1560.n6.nabble.com/gdal-dev-GeoPDF-translation- tt3742508.html#a3742510 Some info also on the wiki, http://trac.osgeo.org/gdal/wiki/USGS_PDF_Topo Eli ___ 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] gdalwarp cutline layer for USGS GeoPDF maps
On Fri, Jan 18, 2013 at 4:08 PM, Kris Andersen kris.ander...@gmail.com wrote: Thanks for the quick replies! I'm still having trouble, but maybe I don't know what the final cropped image should look like? I was thinking all the whitespace and USGS margin info would be removed? That is what I would expect too. When I follow the directions from http://trac.osgeo.org/gdal/wiki/USGS_PDF_Topo I get the output http://biciworks.com/OR_Newport_North_20110824_TM_geo.tiff (warning! 32 MB download) This still seems to have lots of whitespace and margin content, although it is skewed from the original. Is this the right result? I did the same thing and got the same result. If you make a shapefile out of the neatline and view it, you will see that it matches to the black. So it is a correct result but not intended. So we need different values for the neatline. Here are values that I just estimated off of QGIS: Record_Id,wkb_Polygon 1,POLYGON ((420793 4955647,420689 4941858,410784 4942004,410971 4955792)) Using this gives expected results. Does this pdf file have incorrect neatline information? I'll look at some others to see if they work better. This was done using $ gdalwarp -cutline wkt_cutline_file.vrt -cl NEATLINE -crop_to_cutline OR_Newport_North_20110824_TM_geo.pdf OR_Newport_North_20110824_TM_geo.tiff with wkt_cutline_file.vrt and NEATLINE.csv copied from the Wiki. When I try the same command with the GeoPDF I linked to, all I get is an ugly black square. This is after changing NEATLINE.csv accordingly with the metadata from VA_Strasburg_20110524_TM_geo.pdf, specifically, NEATLINE.csv Record_Id,wkb_Polygon 1,POLYGON ((739349.486192459356971 4305760.633085563778877,726989.596524115651846 4305396.499421719461679,726535.950552191701718 4320794.730121357366443,738895.840220535406843 4321158.863785205408931,739349.486192459356971 4305760.633085563778877)) I noticed the mailing list post pays particular attention to GDAL_PDF_DPI. $ gdalwarp -crop_to_cutline -cutline $i.csv -co GDAL_PDF_DPI=250 -of GTiff $i $i.tiff If I'm not mistaken, I think this line should be $ gdalwarp -crop_to_cutline -cutline $i.csv --config GDAL_PDF_DPI 250 -of GTiff $i $i.tiff I think you are correct but I'm not certain. Regardless, setting the resolution to 250 dpi doesn't help matters for me. I also tried 400 and 508 dpi, which is what USGS claims the high-resolution scans are, but that was also a dead end. Any ideas what's going on here? One thing: I did notice my output of gdalinfo --formats is slightly different from the Wiki. Could this have anything to do with it? I don't think that matters but is a result of a recent reformatting of the output, http://lists.osgeo.org/pipermail/gdal-dev/2013-January/035200.html has more. HTH, Eli $ gdalinfo --formats | grep PDF PDF (rwvs): Geospatial PDF The Wiki has PDF (rov): Geospatial PDF. Thanks, Kris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Neatline for USGS PDF maps
Checking over some USGS topo PDFs, the neatline reported appears too large. Has anyone else check this or noticed anything similar? Specific details below. I did the same thing and got the same result. If you make a shapefile out of the neatline and view it, you will see that it matches to the black. So it is a correct result but not intended. So we need different values for the neatline. Here are values that I just estimated off of QGIS: Record_Id,wkb_Polygon 1,POLYGON ((420793 4955647,420689 4941858,410784 4942004,410971 4955792)) Using this gives expected results. Does this pdf file have incorrect neatline information? I'll look at some others to see if they work better. It looks to me that the USGS topo pdf from http://ims.er.usgs.gov/gda_services/download?item_id=5365522 reports a neatline that covers most of the pdf, NEATLINE=POLYGON ((421614.539994676539209 4956417.675689895637333,421413.787766160559841 4941008.479600958526134,409984.382813899661414 4941157.382794972509146,410185.135042413836345 4956566.578883905895054,421614.539994676539209 4956417.675689895637333)) but should cover much less area as estimated out of QGIS above. Is this an error within the file or an error in what gdalinfo reports or something else? If it is an error in the file, I can contact the USGS liaison for the Pacific Northwest to see if it can be fixed (at least for Oregon). I checked other USGS Topos in OR, CO, MI and found the same problem. I tried some in ND and IA and the neatline seemed correct. Specifically, http://ims.er.usgs.gov/gda_services/download?item_id=5154397quad=Grangerstate=IAgrid=7.5X7.5series=TNM%20GeoPDF and http://ims.er.usgs.gov/gda_services/download?item_id=5251428quad=Nelson%20Lakestate=NDgrid=7.5X7.5series=TNM%20GeoPDF It is great to have the pdf driver to make more data accessible. GDAL/OGR always makes me smile when I encounter data in some new to me format and it is already supported (in the last few months, SEG-Y). Best Regards, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Absolutely no progress trying to compile GDAL with Oracle support on Windows
On Tue, Nov 27, 2012 at 5:04 PM, cheesybiscuits thomaschrist...@gmail.comwrote: Jukka - Thanks for the suggestion. I have extracted the contents of release-1600-gdal-mapserver.zip (Compiled binaries in a single .zip package ) which seems to include the Oracle plugin (gdal_GEOR.dll and ogr_OCI.dll). Typically to use any of these distributions, you need to run the .bat file to establish the proper environment settings. Did you run SDKShell.bat or similar in the shell before trying to use it? Often, that .bat only sets it for the duration and context of that shell. However OCI is still not listed in gdalinfo --formats, and running my original ogr2ogr command still fails due to not having the right driver. You might want to also run gdalinfo --version to see if you are indeed running what you think you are running instead of some other installation that may be on your computer. HTH, Eli Is anything special required to enable / load these plugins when using gdal tools? I assume this is the case because I also don't see the FGDB format listed which is also supposed to be included. Thanks again -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Absolutely-no-progress-trying-to-compile-GDAL-with-Oracle-support-on-Windows-tp5018926p5019194.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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ORA-01406 error when reading many attributes from Oracle
Jukka, Could it be possible that OCI driver reserves too little of some resourses and fails because of that with large records? I am now running a query with minimum set of columns in my query and ogr2ogr is running well and I believe it will convert all the million rows from the view now. The view schema does not look extra hard for me. There are 21 attributes in the view and the longest VARCHAR2 is just 100 chararters long. This may be overly simplistic, but does the cast operator do anything? SELECT *, CAST(OGR_STYLE AS character(255)) FROM rivers Eli -Jukka Rahkonen- ___ 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] clipping multiple shapefiles from a set of clipping polygons
On Tue, Oct 9, 2012 at 3:41 AM, maning sambale emmanuel.samb...@gmail.com wrote: I see, is there a scripting workaround using 1.9? ogr2ogr has various -clip. options. It looks like you could specify using a particular feature in the AdminPoly to do this (presumably GEOS support is required?). ogr2ogr -f ESRI shapefile output.shp input.shp -clipsrc AdminPoly.shp -clipsrclayer AdminPoly -clipsrcsql SELECT * FROM AdminPoly WHERE AttributeName_in_AdminPoly='Some_value' If you don't have other requirements for the stable release, there are lots of binaries including nightly builds for some platforms, http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries HTH, Eli On Mon, Oct 8, 2012 at 9:14 PM, Etienne Tourigny etourigny@gmail.com wrote: generally speaking new features do not go into current stable version (1.9), they will be incorporated into next stable version (probably 2.0). Etienne On Mon, Oct 8, 2012 at 9:57 AM, Ari Jolma ari.jo...@gmail.com wrote: On 10/08/2012 03:21 PM, maning sambale wrote: Thanks! Is this implemented already in the stable build? It's currently only in the trunk version. Ari Maning Sambale (mobile) On Oct 8, 2012 7:28 PM, Ari Jolma ari.jo...@gmail.com wrote: On 10/08/2012 02:13 PM, maning sambale wrote: HI, I have a shapefile polygon that contains administrative boundaries and a several shapefile of various features. I want to create separate shapefiles of each layer feature for each administrative boundaries in the clipping layer. For example, AdminPoly1 - AdminPoly1_point.shp - AdminPoly1_line.shp - AdminPoly1_poly.shp AdminPoly2 - AdminPoly1_point.shp - AdminPoly1_line.shp - AdminPoly1_poly.shp and so on. Any advice? Maning, The new layer methods may be what you're looking for: http://trac.osgeo.org/gdal/wiki/LayerAlgebra Ari ___ 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 -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ 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] gdalwarp with packbits compression: output too large
Rutger, There are some notes on this on the wiki too, http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#GeoTIFFoutput-coCOMPRESSisbroken Regards, Eli On Thu, Sep 13, 2012 at 8:16 AM, Rutger kass...@gmail.com wrote: Thanks for the tip, i wasn't aware of the -wo flags. Im testing it right now, but at 20% its already taking 20 minutes, so its certainly not very practical, but im curious of the result. For comparison, the earlier mentioned gdalwarp operation takes 72 seconds, running gdal_translate after it takes another 11 seconds. :) I noticed some bugfixes from 5 and 6 years ago mentioning compression and gdalwarp, but for a case of lots of small files. Maybe that would be a situation where the extra flag would be useful. Regards, Rutger -- View this message in context: http://osgeo-org.1560.n6.nabble.com/gdalwarp-with-packbits-compression-output-too-large-tp5001731p5001737.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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to cut a Raster map with a KML file
Luis, On Tue, Sep 11, 2012 at 11:14 AM, Luis Lisboa luislisboa1...@gmail.com wrote: Hi Eli Probably I was not clear: When I use this it outputs a geotiff with two bands: 1 with the real data and another one with the mask of the pixels that fall inside each polygon. I just want to have an output file with one band (band 1) and without the mask. Is it possible? Sometime images can clean up just be running them through gdal_translate. -ot or -b or -mask or some combination may additionally be needed. http://gdal.org/gdal_translate.html Does gdal_translate on your file collapse the mask band into a single band with no data values? rgb2pct.py can be used to convert RGB/RGBA to single band with a color table. I'm not sure if it would work with a two band image, one being the mask but you can try it and see what it does. HTH, Eli Thanks Luis On Thu, Sep 6, 2012 at 4:50 AM, Eli Adam ea...@co.lincoln.or.us wrote: Luis, On Wed, Sep 5, 2012 at 3:00 AM, Luis Lisboa luislisboa1...@gmail.com wrote: Thank you Chitanya. But it created an output file with two layers (one with the values from original file and another with a 255 for the pixels thar are inside KMZ file: How can I have produce one layer? I may be thinking of something else based on your description. If you got an output that has the original values in the area of the kmz and an alpha mask band over the other areas I think that would be expected. You can also use -crop_to_cutline to remove that 'extra' data. If that isn't what you are talking about, you may want to use ogr2ogr to convert your kmz to a shapefile in the same projection as your input raster and see if it gives you a better result. Bests, Eli Thanks Luis On Mon, Sep 3, 2012 at 5:10 PM, Chaitanya kumar CH chaitanya...@gmail.com wrote: Luis, gdalwarp has some options for this exact purpose. The cutline can be from any of the OGR readable datasource. http://www.gdal.org/gdalwarp.html On Mon, Sep 3, 2012 at 9:34 PM, Luis Lisboa luislisboa1...@gmail.com wrote: Greetings I have a raster file (Geotiff) and I have a KML file with a polygon and I want to cut raster map to only have valid values inside the polygon. How can I do this using just GDAL? Usually I used to cut geotiff file with gdalwarp and but in those cases I was cutting a square (xmin xmax ymin ymax) and in this case is a more complex polygon Thanks Regards, Luis ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to cut a Raster map with a KML file
Luis, On Wed, Sep 5, 2012 at 3:00 AM, Luis Lisboa luislisboa1...@gmail.com wrote: Thank you Chitanya. But it created an output file with two layers (one with the values from original file and another with a 255 for the pixels thar are inside KMZ file: How can I have produce one layer? I may be thinking of something else based on your description. If you got an output that has the original values in the area of the kmz and an alpha mask band over the other areas I think that would be expected. You can also use -crop_to_cutline to remove that 'extra' data. If that isn't what you are talking about, you may want to use ogr2ogr to convert your kmz to a shapefile in the same projection as your input raster and see if it gives you a better result. Bests, Eli Thanks Luis On Mon, Sep 3, 2012 at 5:10 PM, Chaitanya kumar CH chaitanya...@gmail.com wrote: Luis, gdalwarp has some options for this exact purpose. The cutline can be from any of the OGR readable datasource. http://www.gdal.org/gdalwarp.html On Mon, Sep 3, 2012 at 9:34 PM, Luis Lisboa luislisboa1...@gmail.com wrote: Greetings I have a raster file (Geotiff) and I have a KML file with a polygon and I want to cut raster map to only have valid values inside the polygon. How can I do this using just GDAL? Usually I used to cut geotiff file with gdalwarp and but in those cases I was cutting a square (xmin xmax ymin ymax) and in this case is a more complex polygon Thanks Regards, Luis ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics
Band 1 Block=5000x1 Type=Int16, ColorInterp=Gray ... Band 1 Block=1x1 Type=Float32, ColorInterp=Gray I can't see anything obvious why these two files can't be mosaiced.. It looks like one is 16 bit and the other 32. gdalbuildvrt probably can't determine the type of output to create. What is the output type of gdalwarp on the same files? Did gdalwarp do anything to make the input files match in the output? HTH, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
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://activityworkshop.net/software/gpsprune/index.html, which did what I wanted but better. I think that this would be a useful utility. Eli On Mon, Jul 23, 2012 at 8:26 AM, Daniel Morissette dmorisse...@mapgears.com wrote: 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 such as MapServer, and even for Desktop apps with hundreds of images. If I needed this kind of functionality myself I would use a script to create an OGR point file as suggested by Even, to avoid the overhead caused by opening all the images. My 0.02$ Daniel On 12-07-23 5:27 AM, Tamas Szekeres wrote: 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 MapServer) would be capable to utilize this feature. I could imagine a driver configuration file to specify which driver should be used for a particular image format and where the specific information is located, I don't require to harmonize the metadata structure at this time. We should probably allow mixing jpegs and tiffs in the same directory, but the configuration should specify how the similar attributes are provided by each (sub)driver. Best regards, Tamas 2012/7/23 Even Rouault even.roua...@mines-paris.org mailto:even.roua...@mines-paris.org 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 point feature, the positions would be extracted from the exif information. The file name and path would be provided as an attribute for each feature. This data source could then be used by higher level apps to provide symbols at the picture locations in the map and display the picture when the feature is selected. The driver would definitely use GDAL to extract information about the provided images. I'm not sure whether we already have some kind of alternative solution to this, let me know if you know about any. Further ideas about this topic would also be helpful. The JPEG driver already exposes EXIF information if found : $ gdalinfo ../autotest/gdrivers/data/albania.jpg Driver: JPEG/JPEG JFIF Files: ../autotest/gdrivers/data/albania.jpg Size is 361, 260 Coordinate System is `' Metadata: [...] EXIF_GPSLatitude=(41) (1) (22.91) EXIF_GPSLatitudeRef=N EXIF_GPSLongitude=(19) (55) (42.35) EXIF_GPSLongitudeRef=E [...] $ gdalinfo ../autotest/gcore/data/exif_and_gps.tif -mdd EXIF Driver: GTiff/GeoTIFF Files: ../autotest/gcore/data/exif_and_gps.tif Size is 1, 1 Coordinate System is `' [..] 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 knowledge, the JPEG driver, and recently the GTiff driver, are the only one that extract EXIF for now. I see that the JPEG driver exposes it in the default metadata domain, whereas I chose EXIF for the GTiff driver. For GTiff, the specific EXIF metadata domain seemed better to me to avoid 'polluting' the default metadata domain, but I didn't want to change the JPEG driver at that point. But this would probably requires some harmonization. So with some scripting, you could create for example a point shapefile, with the filename as attribute and GPS position as geometry. In its syntax, this could be something similar to gdaltindex. Doing that as a OGR driver would be also doable of course. The only point to solve is the definition of the connexion string to specify the image set. Best regards, Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Updating shapefile fields name with ogr2ogr
I've also found this very confusing and unexpected. Once I did figure it out it has been very useful. Could ogrinfo CHEMIN.shp -sql ALTER TABLE CHEMIN RENAME COLUMN prec_alti TO foo or similar be added as an example to http://gdal.org/ogrinfo.html and perhaps also as a 'note about ogrinfo with OGR SQL' on http://gdal.org/ogr/ogr_sql.html? Perhaps http://gdal.org/ogr/ogr_sql.html could be updated from: -sql statement: Execute the indicated SQL statement and return the result. to something like: -sql statement: Execute the indicated SQL statement and return the result. In place updates (ALTER TABLE) are also permitted. Eli On Thu, Jun 21, 2012 at 11:03 PM, Hermann Peifer pei...@gmx.eu wrote: On 2012-06-20 19:50, Even Rouault wrote: I know this is going to sound a bit counter-intutive at first... ogrinfo opens datasources in read/write mode by default... Just out of curiosity: why does an ...info tool use read/write mode by default? One would expect that it only needs to *read* some info in the data source? Hermann ___ 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] to find area of shapeFile
Siva,
I'm not sure how to help you with the below code. Perhaps if you
explain the error someone else on the list might be able to help.
My suggestion was how to get the area using the command line tool ogr2ogr.
Regards, Eli
On Thu, Jun 14, 2012 at 1:16 AM, SIVA RAMA KRISHNA
s.r.kriis...@gmail.com wrote:
Eli Adam,
i am Trying To Find Area of A Polygon
with the Following Code
int main()
{
OGRRegisterAll();
OGRLayer *poLayer;
OGRFeature *poFeature;
OGRDataSource *poDS;
poDS = OGRSFDriverRegistrar::Open( first.shp);
poLayer = poDS-GetLayerByName( first);
int nCount=poDS-GetLayerCount();
printf(%d,nCount);
poLayer-ResetReading();
OGRGeometry *poGeometry;
OGRGeometryCollection *PoGC;
while((poFeature=poLayer-GetNextFeature())!=NULL)
{
int nCnt=poFeature-GetFieldCount();
printf(\n %d,nCnt);
qDebug()entered;
poGeometry=poFeature-GetGeometryRef();
if(poGeometry !=NULL
wkbFlatten(poGeometry-getGeometryType()) == wkbPolygon)
{
PoGC-addGeometry(poGeometry);
double area = PoGC-get_Area() ;
qDebug() area ;
}
}
return 0;
}
i am getting Error
With Regards
siva
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] to find area of shapeFile
I'm just guessing here since not much of an email or question made it through. You can look at this, http://gdal.org/ogr/ogr_sql.html, specifically OGR_GEOM_AREA HTH, Eli On Tue, Jun 12, 2012 at 4:21 AM, SIVA RAMA KRISHNA s.r.kriis...@gmail.com wrote: ___ 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] bring through shapefile attribute in gdal_rasterize
Derek, This may be a simple question for most of you but I thought I would ask it anyhow as I am at an impasse. I have a Counties shape file. I am attempting to convert it to raster utilizing gdal_rasterize, and this does work. However, I am attempting to carry into the output file the county name preferably e.g. Orange County, or at least a county identify of some kind. I have utilized a command similar to the following: gdal_rasterize -a COUNTY -l -sql select COUNTY, * from Counties Counties Counties.shp CountiesRaster.tif I think that -l should specify the layer name from the source dataset not the field. Typically in a shapefile there is only one layer and it is the same as the shapefile name. Try dropping the -l stuff all together. gdal_rasterize -a COUNTY Counties.shp CountiesRaster.tif or if you use it, use it like this: gdal_rasterize -a COUNTY -l Counties Counties.shp CountiesRaster.tif However, when I open the resulting raster file in ArcGIS and click on one of the pixel to identify it I don’t see the county name. Is the county name there and I am just not seeing it in ArcGIS indentify. I realize there are probably more GDAL intensive ways to check for the data, but I am still learning. I was hoping to someone could explain to me what I am doing incorrectly. You can get information from a raster in GDAL with gdallocationinfo. HTH, Eli Thanks, Derek ___ 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] Ogr2OGR for GeoJSON fails on windows 7
Vivek, I think you might have some minor typos: ogr2ogr -f geoJSAON CENO.json CENOVUS.shp GeoJSON not geoJSAon [no ending double quote either] HTH, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Ogr2OGR for GeoJSON fails on windows 7
Vivek, My bad , i did typo in writing here. I have written correctly as GeoJSON for conversion. Are you saying that you typed it correctly on the command line and it still doesn't work? If so, can you copy your command and error from the command line to the email? Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: strange behaviour with gdalwarp and LZW compression
Stefano, I think that is expected. You can read a little more about it and a recommended work around (VRT) here, http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#GeoTIFFoutput-coCOMPRESSisbroken Bests, Eli The problem arise if I insert the options -co COMPRESS=LZW at the warping. The process end successfully but the resulting geotiff is 6 times the size of the original one! ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: strange behaviour with gdalwarp and LZW compression
Reading further, I learn about OPTIMIZE_SIZE, http://gdal.org/structGDALWarpOptions.html#a0ed77f9917bb96c7a9aabd73d4d06e08 Can OPTIMIZE_SIZE be set from the command line? Eli On Tue, Mar 6, 2012 at 3:41 PM, Eli Adam ea...@co.lincoln.or.us wrote: Stefano, I think that is expected. You can read a little more about it and a recommended work around (VRT) here, http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#GeoTIFFoutput-coCOMPRESSisbroken Bests, Eli The problem arise if I insert the options -co COMPRESS=LZW at the warping. The process end successfully but the resulting geotiff is 6 times the size of the original one! ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Slope in gdaldem
Steve,
additional processing steps they can. How does adding code to gdal work?
Just from an observer perspective, it seems that once you have your
additions worked out, attach a diff on on trac ticket. The details
for how to do that are: sign up for an osgeo userid,
http://www.osgeo.org/osgeo_userid (if you don't already have one),
login to the gdal trac and then open a new ticket,
http://trac.osgeo.org/gdal/report
I don't know the likelihood of one of the developers adding it in,
someone might comment on the ticket about that (could depend on the
code, impacts to other parts, etc). Putting it in a ticket also makes
it available to anyone that may want to locally apply it for
themselves.
HTH, Eli
Best,
Steve
float GDALSlopeHydroAlg (float* afWin, float fDstNoDataValue, void* pData)
{
// Hydrologic Slope is the max
// local slope btw center cell and adjacent cells
const double radiansToDegrees = 180.0 / M_PI;
GDALSlopeAlgData* psData = (GDALSlopeAlgData*)pData;
double key;
float pafLocalMin = afWin[0];
float pafLocalMax = afWin[0];
for ( int k = 1; k 9; k++)
{
if (afWin[k] pafLocalMin)
{
pafLocalMin=afWin[k];
}
if (afWin[k] pafLocalMax)
{
pafLocalMax=afWin[k];
}
}
key = afWin[4] - pafLocalMin;
if (key 0)
{
key = afWin[4] - pafLocalMax;
}
if (psData-slopeFormat == 1)
return (float) (atan(sqrt(key) / (2*psData-scale)) *
radiansToDegrees);
else
return (float) (100*(sqrt(key) / (2*psData-scale)));
}
___
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] ogr2ogr creates empty shape files
Wolfgang, how would one prevent OGR2OGR from creating an empty target files when a WHERE condition returns no records from the source files? This I know that there is a COUNT() that can be used in the SELECT part. I've never tried it in the WHERE part. You might be able to try that. question came up during a batch process where dozens or even hundreds of files are converted and further processed. Is there an option besides of manually deleting those files? Depending on how you are doing your batch process, you can use ogrinfo with COUNT() as a test to decide if you should do the ogr2ogr part. HTH, Eli TIA wolfgang ___ 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] gdal post - boundary polygone for rectified images
Gianluca, Or if just there is a way to create a vector file showing the boundary of the rectified image. What I am searching is a script in gdal style in order to automate the procedure for several rasters without further user input. OGR has tindex which makes a shapefile outline of rasters, http://gdal.org/ogrtindex.html HTH, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR SQL CAST and field name alias selects incorrect fields in some cases
Hi all, I'm trying to use OGR SQL to CAST and field name aliasing together and getting incorrect results (or issuing incorrect commands) when combined with two LEFT JOINs on MDB (both ODBC and MDB drivers). The results are incorrect in that the fields are populated with incorrect information, specially, filling it with other fields that are not selected at all. I'm seeing this in windows close to trunk (ODBC) and a statically compiled ubuntu 10.04 trunk from a few months ago (Access MDB/Java/Jackess). The data is somewhat messy so it could be a case of ambiguous table/query names after some shortening is applied or something similar although nothing jumps out in that regard to me. Both the tables that are joined to have a field named DocumentName. Also, the way I am using the CAST in this case isn't needed but I ran into it and wanted to report it. The simple case works as I expect: ogr2ogr surveys_simply_cast2.shp Surveys.shp -sql SELECT CAST(surveyid AS character(255)) AS surveyid_alias, COMMENT FROM Surveys Warning 6: Normalized/laundered field name: 'surveyid_alias' to 'surveyid_a' Specifically, I get a field named surveyid_a that is character 255 and has the correct content: ogrinfo -al -so surveys_simply_cast2.shp surveys_simply_cast2 ... surveyid_a: String (255.0) COMMENT: String (15.0) Now I try the same thing with two LEFT JOINs to mdb/ODBC: ogr2ogr surveys_output_two_fields.shp Surveys.shp -sql SELECT CAST(webimage AS character(255)) AS webimage_1, CAST(SubdivisionName AS character(255)) AS Subdivisio FROM Surveys LEFT JOIN 'ODBC:cygwinSurveys'.Local_Survey_Image ON Surveys.surveyid=Local_Survey_Image.DocumentName LEFT JOIN 'ODBC:cygwinSurveys'.Survey ON Surveys.surveyid=Survey.DocumentName Warning 6: Field FileDate create as date field, though DateTime requested. This gives me the fields that I expect: ogrinfo -al -so surveys_output_two_fields.shp surveys_output_two_fields ... webimage_1: String (255.0) Subdivisio: String (255.0) However, they are populated with incorrect information. The field webimage_1 is filled with values from the field cygwinSurveys.Survey.Comments. The field Subdivisio is filled with values from cygwinSurveys.Survey.ImagePilot (or Net_PDF - yes there are two fields with identical information). Adding --debug ON shows that these tables don't have FID columns (I could not see all the debug content but that seemed to be the only non-routine information): OGR_ODBC: Table Local_Survey_Image has no identified FID column. ... On Ubuntu, the results are the same, my command is: LD_LIBRARY_PATH=.:/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client ogr2ogr /tmp/surveys_etl/surveys.shp /tmp/surveys_etl/Surveys.shp -sql SELECT Surveys.surveyid AS SURVEYID,DocumentName AS DocumentNa,SurveyorKey as SurveyorKe,CAST(webimage AS character(255)) AS webimage_1,FileDate,Client, SurveyType,ClerkNumber AS ClerkNumbe,CAST(SubdivisionName AS character(255)) AS Subdivisio FROM Surveys LEFT JOIN '/tmp/surveys_etl/Surveys.mdb'.Survey ON Surveys.surveyid=Survey.DocumentName LEFT JOIN '/tmp/surveys_etl/Surveys.mdb'.Local_Survey_Image ON Surveys.surveyid=Local_Survey_Image.DocumentName Excluding the CAST gives the correct results: ogr2ogr surveys_output_no_cast.shp Surveys.shp -sql SELECT webimage AS webimage_1, SubdivisionName AS Subdivisio FROM Surveys LEFT JOIN 'ODBC:cygwinSurveys'.Local_Survey_Image ON Surveys.surveyid=Local_Survey_Image.DocumentName LEFT JOIN 'ODBC:cygwinSurveys'.Survey ON Surveys.surveyid=Survey.DocumentName Trying to reintroduce the CAST with only one join works correctly (for either join): ogr2ogr surveys_output_singel_join.shp Surveys.shp -sql SELECT CAST(webimage AS character(255)) AS webimage_1 FROM Surveys LEFT JOIN 'ODBC:cygwinSurveys'.Local_Survey_Image ON Surveys.surveyid=Local_Survey_Image.DocumentName ogr2ogr surveys_output_singleb.shp Surveys.shp -sql SELECT CAST(SubdivisionName AS character(255)) AS Subdivisio FROM Surveys LEFT JOIN 'ODBC:cygwinSurveys'.Survey ON Surveys.surveyid=Survey.DocumentName I can package this up for download by anyone interested, just contact me offline for the link. (I can also include the statically compiled binary as well although it may only work on Ubuntu 10.04 with Java/Jackess/etc and called setting LD_LIBRARY_PATH.) Bests, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Some tables from mdb not exported to PostGIS
Assuming that you are using ogr2ogr on the xp computer, you can fairly easily setup ODBC connections for the non-spatial tables, http://gdal.org/ogr/drv_odbc.html Doing the same from linux is somewhat more difficult, the easiest path I think to be http://gdal.org/ogr/drv_mdb.html You can see some of my previous similar attempts, http://lists.osgeo.org/pipermail/gdal-dev/2011-November/030833.html And this general topic seems to be ongoing so which version you are using may be relevant depending on specifics, http://trac.osgeo.org/gdal/changeset/23931 Bests, Eli On Fri, Jan 27, 2012 at 6:50 PM, jjap sab...@gmail.com wrote: Greetings, ogr2ogr has allowed me to successfully convert an ESRI personnal geodatabase from a Windows XP computer to an Ubuntu server 11.04 running PostGIS 1.5 with proper encoding . The tables containing the blob/shapefiles all made it but not the others. Am I right to presume I'll have to migrate those other tables by hand and rebuild references? Am I missing some options which would have allowed me to do it in one fell swoop? Any hints appreciated. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Some-tables-from-mdb-not-exported-to-PostGIS-tp4344999p4344999.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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] extra spaces when writing to AAIGRID format
Brad, E.g., if I try to write a 3x3 grid that ArcGIS can read, it needs to look something like this: ncols 3 nrows 3 xllcorner 100. yllcorner 100. cellsize 0.1000 1.0 1.4809201955795288 1.4809201955795288 0.11773009598255157 0.15476560592651367 0.86710774898529053 0.17429724335670471 0.76037305593490601 10.00 Instead, the ascii file written by GDAL looks like this (which can't be read by ArcGIS because of extra leading spaces in the first line of the data): What is the ArcGIS error? I tried these files on ArcMap 9.3 and 10.0 and had no issues that I realized. (to display in a meaningful manner, I had to change the symbology which required the calculation of statistics in ArcGIS. I also changed the cellsize to .1 so I could more easily examine the pixels and values.) Below looks like a 3x4 grid that is labeled as 5x5 but even that worked for me in ArcGIS (didn't throw error but values were not where 'expected'). ncols 5 nrows 5 xllcorner 100. yllcorner 100. cellsize 0.1000 1 1.4809201955795288 1.4809201955795288 0.25947147607803345 0.71342569589614868 2.810183288701 0.11773009598255157 0.15476560592651367 0.86710774898529053 0.17429724335670471 0.76037305593490601 10 0.74458205699920654 All 4 of of Even's files worked for me too. HTH, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] editor that color codes mapfile syntax?
There is also a plugin for scite (http://www.scintilla.org/SciTE.html). This link for the MapServer plug in is dead but you can still find it on archive.org http://ms.gis.umn.edu:8081/ms_plone/docs/link http://web.archive.org/web/20100913161428/http://ms.gis.umn.edu:8081/ms_plone/docs/link You will need to edit the SciTEGlobal.properties file to enable it. I've attached the map.properties as well. Bests, Eli PS. you might notice that this is slightly out of date and thus probably doesn't have full MapServer 6.0 syntax highlighting. On Tue, Dec 13, 2011 at 2:03 PM, jdm jdmor...@unca.edu wrote: Thanks Michael, This is a great little utility. Cheers, Derek On 12/13/2011 2:15 PM, Smith, Michael wrote: http://sites.google.com/site/gianpierocampanella/files * Michael Smith State GIS Manager, Maine Office of GIS, Maine OIT Board Member, Maine GeoLibrary Board Member, Maine GIS Users Group State Rep, National States Geographic Information Council | MEGIS | GeoLibrary | MEGUG | NSGIC | State House Station 174 264 Civic Center Drive Augusta, ME 04333-0174 (207) 215-5530 69 o 47' 49.5W 44 o 20' 54.5N -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of jdmorgan Sent: Tuesday, December 13, 2011 2:12 PM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] editor that color codes mapfile syntax? Hello, I was wondering if anyone knows of an editor that color codes mapfile syntax? I use notepad++ currently for python, but it would be great to have sytax coloring for .map files. Thanks, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev map.properties Description: Binary data ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] .ovr files and Lanczos
Are .ovr files just tifs with a different file extension? If so, could you use, gdalwarp -tr # # -r lanczos output.ovr? Eli On Mon, Nov 28, 2011 at 10:57 PM, Chaitanya kumar CH chaitanya...@gmail.com wrote: Robb, Note that the quality is effected by the levels you choose. Can you provide a small part of the image where the overview is garbled the most. On Tue, Nov 29, 2011 at 12:00 PM, Robb Wright robbkwri...@gmail.com wrote: Thanks Chaitanya. Unfortunately gdaladdo doesn't support the Lanczos resampling type. Lanczos creates - by far - the best looking downsampled images for my type of rasters. What I'm looking for is a way to create pyramid layers/.ovr files using the Lanczos resampling method. Robb On 11/29/2011 12:58 AM, Chaitanya kumar CH wrote: Robb, If you are using gdal version 1.6 or later, you can use the -ro option[1]. It opens the tiff file in read-only mode and creates external overview. [1]: http://www.gdal.org/gdaladdo.html On Mon, Nov 28, 2011 at 11:53 PM, Robb Wright robbkwri...@gmail.com wrote: I'm working with indexed color types of raster data (charts). The data is in RGB geotiffs and I'm using gdaladdo to create pyramid layers for them. Unfortunately, the best method for this raster type available using gdaladdo is still pretty bad - much of the linework becomes garbled when viewing the pyramids. The best-looking method that I've been able to come up with is: gdaladdo.exe --config COMPRESS_OVERVIEW DEFLATE -r average The Lanczos algorithm method works beautifully when used with other programs - but I need to create .ovr files. gdal_retile.py output looks great - but I can't figure out how to create .ovr files from that output. Does anybody know of the availability of the Lanczos resampling method for gdaladdo - or of another way to create .ovr files with Lanczos? Robb ___ 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 -- 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] A gdal-users mailing list?
Hermann, Just a note that this topic has been on the list before, http://lists.osgeo.org/pipermail/gdal-dev/2010-March/023779.html Bests, Eli Hi all, Could it (perhaps) make sense to have a gdal-users mailing list, in analogy to grass-users, qgis-users, etc. ? I assume that, according to some logic, GDAL/OGR is considered to be a library from/for developers, not a GIS application for end-users. On the other hand, there are quite some documented utilities around [1], utilised by gdal-users like me. Actually, if I compare [1] with [2], I see that my make install installs many more utilities/scripts than mentioned on the GDAL Utilities page. Users might have (..hmm..) simple questions that real developers might consider to be (..hmm..) not so interesting. gdal-users could be a list where experienced users reply to newcomers, with the side-effect of reducing some traffic on gdal-dev. Hermann [1] http://www.gdal.org/gdal_utilities.html [2] $ make install 1 libtool: install: (...) gdalinfo 2 libtool: install: (...) gdal_translate 3 libtool: install: (...) gdaladdo 4 libtool: install: (...) gdalwarp 5 libtool: install: (...) nearblack 6 libtool: install: (...) gdalmanage 7 libtool: install: (...) gdalenhance 8 libtool: install: (...) gdaltransform 9 libtool: install: (...) gdaldem 10 libtool: install: (...) gdallocationinfo 11 libtool: install: (...) gdalsrsinfo 12 libtool: install: (...) gdal_contour 13 libtool: install: (...) gdaltindex 14 libtool: install: (...) gdal_rasterize 15 libtool: install: (...) gdal_grid 16 libtool: install: (...) ogrinfo 17 libtool: install: (...) ogr2ogr 18 libtool: install: (...) ogrtindex 19 libtool: install: (...) testepsg 20 libtool: install: (...) gdalbuildvrt 21 libtool: install: (...) scripts/epsg_tr.py 22 libtool: install: (...) scripts/esri2wkt.py 23 libtool: install: (...) scripts/gcps2vec.py 24 libtool: install: (...) scripts/gcps2wld.py 25 libtool: install: (...) scripts/gdal2tiles.py 26 libtool: install: (...) scripts/gdal2xyz.py 27 libtool: install: (...) scripts/gdal_calc.py 28 libtool: install: (...) scripts/gdalchksum.py 29 libtool: install: (...) scripts/gdal_fillnodata.py 30 libtool: install: (...) scripts/gdalident.py 31 libtool: install: (...) scripts/gdalimport.py 32 libtool: install: (...) scripts/gdal_merge.py 33 libtool: install: (...) scripts/gdal_polygonize.py 34 libtool: install: (...) scripts/gdal_proximity.py 35 libtool: install: (...) scripts/gdal_retile.py 36 libtool: install: (...) scripts/gdal_sieve.py 37 libtool: install: (...) scripts/mkgraticule.py 38 libtool: install: (...) scripts/pct2rgb.py 39 libtool: install: (...) scripts/rgb2pct.py ___ 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] Re: OGR2OGR and SQL Spatial
Fred, You may need to use -f with the Code from this page: http://gdal.org/ogr/ogr_formats.html (-f MSSQLSpatial) HTH, Eli On Wed, Nov 16, 2011 at 4:21 PM, Fred Jones fredjo...@gmail.com wrote: Hi Sig, This is the command I have so far. When I execute it, I just get the help returned, no error and no table created: ogr2ogr -overwrite -s_srs EPSG:32100 -t_srs EPSG:4326 -f MSSQL:server=ELMER;database=CENSUS_2010;trusted_connection=yes MSSQL:server=ELMER;database=HT_2010_10;tables=temp_sublocs_btc;trusted_connection=yes What am I doing wrong? Thx, - Hide quoted text - On Wed, Nov 16, 2011 at 1:32 AM, Luca Sigfrido Percich sigfr...@tiscali.it wrote: Hi Fred, first of all check if there is an EPSG entry for your coordinate system. Googlin' Montana State Plane NAD 27 EPSG pointed me to the several pages, among with, for example: http://www.eye4software.com/resources/stateplane/ which states: 2500 NAD83 / Montana 32100 So the EPSG code you're looking for is seems to be 32100. Assuming you want to reproject to Lon/Lat WGS84 (EPSG 4326), you need to use the -s_srs and -t_srs parameters: ogr2ogr -s_srs EPSG:32100 -t_srs EPSG:4326 -f MSSQL:... input.csv ___ 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] access attribute (non-spatial) data in .mdb with PGeo Driver
Hi all, On Windows, I'm trying to access non-spatial tables in an .mdb file. With --debug on I see that the absence of a 'GDB_GeomColumns' table is the problem. ogrinfo --debug on Surveys.mdb PGeo: EstablishSession(DRIVER=Microsoft Access Driver (*.mdb);DBQ=Surveys.mdb) ODBC: SQLDriverConnect(DRIVER=Microsoft Access Driver (*.mdb);DBQ=Surveys.mdb) PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase? [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cann ot find the input table or query 'GDB_GeomColumns'. Make sure it exists and tha t its name is spelled correctly. ODBC: SQLDisconnect() I noticed this fairly recent commit, which seems to indicate that this is the desired behavior, http://trac.osgeo.org/gdal/changeset/21550 I was able to access the non-spatial attributes by making a 'GDB_GeomColumns' table and falsely populating it (and ignoring the missing 'GDB_SpatialRefs' table errors). TableName FieldName ShapeType ExtentLeft ExtentBottom ExtentRight ExtentTop IdxOriginX IdxOriginY IdxGridSize SRIDHasZHasM Survey Shape 4 7255394.59721669241841.239197335 7396378.9177745 524650.4612300040 0 141508.958339791 1 0 0 ogrinfo -so Surveys.mdb Survey ERROR 1: 'SELECT srtext FROM GDB_SpatialRefs WHERE srid = 1' failed. [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cann ot find the input table or query 'GDB_SpatialRefs'. Make sure it exists and tha t its name is spelled correctly. INFO: Open of `Surveys.mdb' using driver `PGeo' successful. Layer name: Survey Geometry: Unknown (any) Feature Count: 20790 Extent: (7255394.597217, 241841.239197) - (7396378.917775, 524650.461230) Layer SRS WKT: (unknown) Geometry Column = Shape DocumentName: String (25.0) SurveyDate: DateTime (19.0) ... If the general case requires a 'GDB_GeomColumns' table, could no 'GDB_GeomColumns' table be made a driver config option? I noticed that the new Access MDB driver, http://gdal.org/ogr/drv_mdb.html , does not require a GDB_GeomColumns table (tested on ubuntu 10.04 and gdal trunk). Thanks, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] access attribute (non-spatial) data in .mdb with PGeo Driver
Thanks Even. I'm confused because if you get to the point of having the trace PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase? it means that you got after the test of r21550 (which should have discared this mdb as having no GDB_GeomColumns table), so I highly suspect you are not using trunk version for this test. Correct. I'm using an old OSGeo4W 1.8dev. Yes, I should have noticed that I was not using the results of that r21550. r21550 only enforces what existed before : the PGeo driver can only handle PGeo MDBs. The new test was introduced specifically to avoid the PGeo driver to try opening a MDB that should be recognized by the Geomedia driver (new in trunk). I confirmed that I don't get that trace with the gisinternals release-1600-gdal-mapserver (from about 2 weeks ago). I also checked with this before writing the list, but just checked that trunk also didn't open the file. I didn't redo the --debug on portion. Why not using the generic ODBC driver for that use case ? This is apparently what I should have been doing. I'll try that now. Thanks, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogrinfo and PGeo Driver for .mdb file, on Ubuntu
Chris, GDAL 1.9 is trunk so I built from source. You need to first install subversion, a compiler and other things to compile software. Once you have the proper environment, then for the basic GDAL build (which would not include mdb of any sort) it is not too difficult and there are directions on the wiki, http://trac.osgeo.org/gdal/wiki/BuildingOnUnix Adding in more formats and drivers is more difficult. Usually, there are details on the format page, http://gdal.org/ogr/drv_mdb.html and/or the build hints section of the wiki, http://trac.osgeo.org/gdal/wiki/BuildHints For the way I did it for the Access mdb driver, I had to make a file /etc/ld.so.sonf.d/libjvm.conf which just has the path pointing to libjvm.so I did this based on the file not found errors I got after compiling and running ogrinfo on the first attempt. I don't fully understand what is the proper way to address issues like this and there may be better ways. I first learned about it using the FileGDB driver. Here is that thread, http://osgeo-org.1803224.n2.nabble.com/gdal-dev-FileGDB-OGR-driver-test-td6237191.html Even's suggestion about adding to LD_LIBRARY_PATH and these two links are mostly what helped me figure it out. http://stackoverflow.com/questions/480764/linux-error-while-loading-shared-libraries-cannot-open-shared-object-file-no-su and http://replay.waybackmachine.org/20090301081221/http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html HTH, Eli On Tue, Oct 25, 2011 at 12:20 AM, Chris Green chris.gr...@ibstv.co.ukwrote: Hi Eli ** ** Thanks for your suggestion. Despite pulling most of my hair out I still can’t get past the syntax error thrown by the PGeo driver, so I would certainly be interested to follow the alternative approach. However I see in the drv_mdb documentation that GDAL/OGR =1.9.0 is required, yet I can’t find anything for Ubuntu later than 1.8 (from UbuntuGIS unstable). Do you have 1.9 on your Ubuntu, if so could you tell me where I can find it? ** ** ** ** Chris ** ** *From:* Eli Adam [mailto:ea...@co.lincoln.or.us] *Sent:* 24 October 2011 19:32 *To:* Chris Green *Cc:* gdal-dev@lists.osgeo.org *Subject:* Re: [gdal-dev] ogrinfo and PGeo Driver for .mdb file, on Ubuntu ** ** Chris, There is also another route that may work for PGeo, http://www.gdal.org/ogr/drv_mdb.html I recently built that on Ubuntu but have not used it yet. It looks like you are close on the other route though. HTH, Eli On Mon, Oct 24, 2011 at 5:35 AM, Chris Green chris.gr...@ibstv.co.uk wrote: Hi List I’m hoping someone can help me make ogr work under Linux with the PGeo driver, so I can read an ESRI Personal Database .mdb file into Mapserver. I can see from old posts that the basic problem is that MDBTools is a bit ‘flaky’ and needs a DSN based connection rather than connecting direct to the .mdb data. I have been trying to follow the instructions in http://www.gdal.org/ogr/drv_pgeo.html . Having installed unixODBC and MDBTools, I configured the odbcinst.ini and odbc.ini files as suggested and it seems that I have partial success because when I define my datasource in odbc.ini like so: [my_pgeo] Description = Sample PGeo Database Driver = Microsoft Access Driver (*.mdb) Database= /var/www/vhosts/mydomain.com/httpdocs/data/test.mdb then the command ogrinfo PGeo:my_pgeo results in the following: INFO: Open of ‘PGeo:my_pgeo’ using driver ‘PGeo’ successful. Error: syntax error at line:2 col:0 I can’t figure out what or where this syntax error can be. I feel that I am quite close to success but don’t know how to move forward from here. Can anyone point me in the right direction please? Chris ___ 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] ogrinfo and PGeo Driver for .mdb file, on Ubuntu
Chris, There is also another route that may work for PGeo, http://www.gdal.org/ogr/drv_mdb.html I recently built that on Ubuntu but have not used it yet. It looks like you are close on the other route though. HTH, Eli On Mon, Oct 24, 2011 at 5:35 AM, Chris Green chris.gr...@ibstv.co.ukwrote: Hi List ** ** I’m hoping someone can help me make ogr work under Linux with the PGeo driver, so I can read an ESRI Personal Database .mdb file into Mapserver. I can see from old posts that the basic problem is that MDBTools is a bit ‘flaky’ and needs a DSN based connection rather than connecting direct to the .mdb data. ** ** I have been trying to follow the instructions in http://www.gdal.org/ogr/drv_pgeo.html . Having installed unixODBC and MDBTools, I configured the odbcinst.ini and odbc.ini files as suggested and it seems that I have partial success because when I define my datasource in odbc.ini like so: ** ** [my_pgeo] Description = Sample PGeo Database Driver = Microsoft Access Driver (*.mdb) Database= /var/www/vhosts/mydomain.com/httpdocs/data/test.mdb ** ** then the command ogrinfo PGeo:my_pgeo results in the following: ** ** INFO: Open of ‘PGeo:my_pgeo’ using driver ‘PGeo’ successful. Error: syntax error at line:2 col:0 ** ** I can’t figure out what or where this syntax error can be. I feel that I am quite close to success but don’t know how to move forward from here. Can anyone point me in the right direction please? ** ** ** ** Chris ** ** ** ** ** ** ___ 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] gdal/ogr version (was NotImplementedError: Wrong number...)
Ole, Is there a way of telling which one I am using (both when running commandline org2org and when importing the ogr module in python)? ogr2ogr --version will work on the command line for at least the major version number. I'm not sure about in python. HTH, Eli Cheers and thanks Ole ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell
Even, This works for me and the test case included with the initial report. Thank you very much, Eli Even Rouault even.roua...@mines-paris.org 08/28/11 5:25 AM I've applied a fix in trunk in http://trac.osgeo.org/gdal/changeset/22998 . Please test and confirm if it works for you. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_rasterize output off by one pixel/cell
Matt, You may want to look at this ticket and see if it is the same thing. If so, you can add yourself to the cc list and you will get emails when there are updates to the ticket. You can also add any additional relevant information to the ticket. http://trac.osgeo.org/gdal/ticket/3774 Regards, Eli On 8/20/2011 at 11:06 AM, in message aa52f8ac-89dc-4543-a210-0dd0ba9e5...@my.und.edu, Burton-Kelly, Matthew matthew.burton.ke...@my.und.edu wrote: Hello, I'm attempting to create a raster from a shapefile of point data, with grid cells 1 degree square. Although the area I have defined matches up with the origin coordinates I want, and the grid cells match up with a vector 1-degree grid I produced in QGIS, the squares supposedly containing the point data are shifted, it looks like down and to the right. Has anyone encountered this issue before? Here is the command I used: gdal_rasterize -a column name -ts 360 180 -te -180 -90 180 90 -l source layer name in source file source file destination file I have uploaded a screenshot of the output I am describing here: http://www.flickr.com/photos/matthewbk/6059112633 Thanks for any insight, Matt - Matthew Burton-Kelly, M.S. Graduate Student Department of Geology and Geological Engineering University of North Dakota Mobile: (802) 922-3696 matthew.burton.ke...@my.und.edumailto:matthew.burton.ke...@my.und.edu matthew.burtonke...@gmail.commailto:matthew.burtonke...@gmail.com http://www.protichnoctem.com http://und.academia.edu/MatthewBurtonKelly About thirty years ago there was much talk that geologists ought only to observe and not theorize; and I well remember someone saying that at this rate a man might as well go into a gravelpit and count the pebbles and describe the colors. How odd it is that anyone should not see that all observation must be for or against some view if it is to be of any service! -Charles Darwin, in an 1861 letter to Henry Fawcett. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Unwanted partial transparency when clipping
Michael, On 7/6/2011 at 5:35 PM, in message 4e14ff42.50...@cironline.org, Michael Corey mco...@cironline.org wrote: Sure, I've uploaded samples here. http://www.mikejcorey.com/spatial/diablo-box-sample.tif http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif I don't notice the semi-transparency in these scaled down images. Perhaps it is the way your viewer reads the mask? These are the same as the images created by the process I described (but scaled down). To your point about specifying size in the first step -- will that make the process run faster, or does it do the scaling down after it builds the full-resolution image? Also, I notice that my filesize always gets significantly bigger when I do the cutout step, which seems counter-intuitive to me since in theory shouldn't there be less information present once the cutout is done? -cutline does not 'discard' any data. The extent of the data remains the same unless you reset those extents. You can do that with -crop_to_cutline. Here are some details from the gdalwarp page, http://gdal.org/gdalwarp.html : -crop_to_cutline: (GDAL = 1.8.0) Crop the extent of the target dataset to the extent of the cutline. Polygon cutlines may be used as a mask to restrict the area of the destination file that may be updated, including blending. If the OGR layer containing the cutline features has no explicit SRS, the cutline features must be in the georeferenced units of the destination file. When outputing to a not yet existing target dataset, its extent will be the one of the original raster unless -te or -crop_to_cutline are specified. Best Regards, Eli Thanks for your help! Michael Corey On 7/6/11 5:01 PM, Chaitanya kumar CH wrote: Michael, Can you provide screenshots of diablo-combined-center-utm10-70pct-box.tif and diablo-combined-center-utm10-70pct-cutout.tif for comparison? By the way, you can perform the actions of the two gdal_translate commands in the first step with the gdal_merge.py script itself unless you want to use a specific resampling algorithm. On Thu, Jul 7, 2011 at 4:28 AM, Michael Corey mco...@cironline.org mailto:mco...@cironline.org wrote: Hi all: I'm using a shapefile as a clipping mask to cut out the shoreline from some DOQ files that I have merged together. But when I do the clipping step, I end up with unwanted semitransparency in the non-clipped areas. I'm pretty sure the problem is only with my gdalwarp step at the end. Here's my process: gdal_merge.py -init 255 -o diablo-combined-center-utm10.tif file file file file gdal_translate -outsize 70% 70% diablo-combined-center-utm10.tif diablo-combined-center-utm10-70pct.tif ogrinfo -al ./diablo_canyon_detail_clipper.shp //Extent: (, ) - (, ) gdal_translate -projwin diablo-combined-center-utm10-70pct.tif diablo-combined-center-utm10-70pct-box.tif gdalwarp -co COMPRESS=DEFLATE -cutline ./diablo_canyon_detail_clipper.shp diablo-combined-center-utm10-70pct-box.tif diablo-combined-center-utm10-70pct-cutout.tif Can anyone help? Thanks! -- Michael Corey ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /t?a???nj?/ /k?m?r/ +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] gdalwarp over tiles in Plate carée
Greetings I'm using gdalwarp to reproject a few tiles from platecarré to UTM WGS84 (for a specific zone). Originally they are tiles so they don't have any blank space between them but when I reproject to UTM I get a few areas in the borders of the image. What can I do to still have a perfect match between tiles? Thanks Kat Kat, I think that gdal_retile.py does what you want. You can also mosaic them first either with gdalwarp or (if they are large files) gdalbuildvrt and then reproject that one mosaic. More details here: http://gdal.org/gdal_retile.htmlhttp://gdal.org/gdalbuildvrt.html HTH, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp over tiles in Plate carée
Kat, The only practical way I know to avoid these slivers of misalignment due to projections having slightly different rotations is to mosaic first. I've been able to do that with even extremely large files with the help the virtual file format (VRT) of GDAL. If you have tiles in one projection and want to end with a mosaic in a different projection, mosaicing first is probably going to be easier and better. However, if you need to reproject the tiles first and then mosaic you can do that. The way I've done that in the past is a lot of work of reprojecting, then trimming/masking the edges that look bad, then sometimes making a small mosaic of original tiles for the overlap areas, reprojecting and trimming that and so on. It is extremely laborsome and involves lots of hand entry of coordinates. Only do that if there is really no better way. If you can't mosaic first, hopefully someone will suggest a better method (perhaps better management of nodata values?) that is less work than what I used to do before gdalbuildvrt. Best Regards, Eli No in my case i want to reproject them first and only then to create a mosaic. (maybe I was not clear on this) Hello Eli I'm using gdalwarp but I'm getting that blank area in the bottom of my image. When I try to mosaic (or visualize) with other tile (also reprojected with gdal) I get this area that was not suppose to have. Any idea how to avoid this? Thanks Kat 2011/7/8 Eli Adam ea...@co.lincoln.or.us Greetings I'm using gdalwarp to reproject a few tiles from platecarré to UTM WGS84 (for a specific zone). Originally they are tiles so they don't have any blank space between them but when I reproject to UTM I get a few areas in the borders of the image. What can I do to still have a perfect match between tiles? Thanks Kat Kat, I think that gdal_retile.py does what you want. You can also mosaic them first either with gdalwarp or (if they are large files) gdalbuildvrt and then reproject that one mosaic. More details here: http://gdal.org/gdal_retile.html http://gdal.org/gdalbuildvrt.html I think that I gave incomplete/incorrect information. To reproject I think that you will need to do use gdalwarp. gdal_merge.py is also another way to mosaic. Regards, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] changing data type of a shapefile
Ahmet, You can also change geometry type, it is also an option with ogr2ogr [2], -nlt. I've only used -nlt to promote to multi-geometry. Eli On 6/15/2011 at 7:27 AM, in message BANLkTik8UghqaRv8E-pES6OSv-+e=a3...@mail.gmail.com, Chaitanya kumar CH chaitanya...@gmail.com wrote: Ahmet, You can use OGR SQL [1] to typecast fields and other stuff. You can use ogr2ogr [2] with the -sql option and supply the sql statement. [1]: http://trac.osgeo.org/gdal/wiki/rfc21_ogrsqlcast [2]: http://www.gdal.org/ogr2ogr.html 2011/6/15 ahmet temiz ahmettemi...@gmail.com hello how can I change data type of a shapefile by ogr2ogr ? regards -- Ahmet Temiz Jeoloji Müh. Afet ve Acil Durum Yönetimi Başkanlığı Planlama ve Zarar Azaltma Dairesi Başkanlığı Bilgi ve CBS grubu Eskişehir Yolu 10. km. Lodumlu / Ankara Tel : 0 312 2872680 / 1535 Ahmet Temiz Geological Eng. Information Systems - GIS Group Disaster and Emergency Management of Presidency ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +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] ogr2ogr custom coordiante system
Brian, What is the command that you tried? If you can construct the proper proj4 format, it should work for ogr. Exactly matching the string in PostGIS may not work and you may get a new number like 32,000 for a new SRID that was added in PostGIS. This slightly older thread suggests one method to overcome this, http://osgeo-org.1803224.n2.nabble.com/specifiying-the-correct-SRID-when-sending-polygons-to-PostGIS-td2026555.html although I have not tried that myself. If you have the WKT or other format, you can get the PostGIS insert string or proj4 format through spatialreference.org, http://spatialreference.org/ HTH, Eli On 6/14/2011 at 7:33 AM, in message b850b3523e82404c80a8acac40bafdf587524...@ex2010.houstonengineeringinc.com, Brian Fischer bfisc...@houstoneng.com wrote: Hi Everyone, I was wondering if there are any help files or guides on how to define a custom coordinate system to use with the ogr2ogr.exe utility. I am trying to use it to load a shapefile into a PostGIS database. The shapefile is in a custom Minnesota County coordinate system. When I try to define the -a_srs I get an error message that says SRID is unrecognized. I'm assume this is because both OGR and PostGIS does not have the custom SRID defined. I've also tried -1 as the SRID but the utility doesn't like that either. How would I define the custom projection so both OGR2OGR utility and PostGIS recognize it? Regards, Brian Brian Fischer, CFM GIS Manager Houston Engineering, Inc. 6901 East Fish Lake Road, Suite 140 Maple Grove, MN 55369 Phone: Direct: 763-493-6664 / W: 763.493.4522 / M: 763.229.2734 Email: bfisc...@houstoneng.commailto:bfisc...@houstonengineeringinc.com Website: www.houstoneng.comhttp://www.houstonengineeringinc.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo: corner coords in other projection
Jon, gdaltransform does some of this. It looks to do 4 corners you would need to do it four times or list the coordinate pairs on four lines and get four lines of output back. There might be a clever way to take the output of gdalinfo as input into gdaltransform saving you some typing and potential transposing. More here http://gdal.org/gdaltransform.html HTH, Eli On 5/24/2011 at 9:15 AM, in message ff46ee5c24ad134c86774e7498509c3d014a8...@erd-ml1itl.erd.ds.usace.army.mil, Lefman, Jonathan ERDC-TEC-VA jonathan.lef...@usace.army.mil wrote: Hi all, Is there an executable utility that takes the corner coordinates from a gtiff and translates them into another projection system? For example, I have a gtiff in UTM and I want to translate the coordinates of the bounding box (or corners) into WGS84. Or is there a way to do this non-programmatically using a combination of executable utilities? Thanks, Jon -- Jonathan Lefman, PhD Geospatial Research and Engineering Division / Army Geospatial Center Engineer Research and Development Center U.S. Army Corps of Engineers jonathan.lef...@usace.army.mil 703-428-8039 ___ 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] Re: FileGDB OGR driver test
I tried compiling the FileGDB OGR driver on ubuntu 8.04 and got a few errors. On the first step I got: eadam@lgis0229ubuntu:/usr/local/src/gdal$ g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport -Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal -I/home/eadam/filegdb/dist/include -L/home/eadam/filegdb/dist/lib -I/home/eadam/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbDatasource.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbDriver.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbLayer.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbUtils.h:33, from ogr/ogrsf_frmts/filegdb/FGdbUtils.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning Then I added to ~.bashrc: GDAL_DRIVER_PATH=/usr/local/src/gdal export GDAL_DRIVER_PATH then: eadam@lgis0229ubuntu:/usr/local/src/gdal$ ogrinfo --formats ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory Supported Formats: - ESRI Shapefile (read/write) - MapInfo File (read/write) - UK .NTF (readonly) - SDTS (readonly) - TIGER (read/write) ... ... Any suggestions? I've been tracking trunk of gdal for about a year, although always in a simple fashion (no plugins etc). I would not necessarily catch something basic. Best Regards, Eli On 4/12/2011 at 11:47 AM, in message 201104122047.20004.even.roua...@mines-paris.org, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 20:37:06, Smith, Michael ERDC-CRREL-NH a écrit : Even, How do you configure gdal/ogr to build with the linux api? This is a bit involved since there's no ./configure support yet, so I compile it at hand as a plugin Here's the line I use from GDAL root source directory : g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport - Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal - I/home/even/filegdb/dist/include -L/home/even/filegdb/dist/lib - I/home/even/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI You must change the /home/even/filegdb/ paths to where you uncompress the filegdb API And you must define the GDAL_DRIVER_PATH environmenet variable to point to the path where ogr_filegdb.so is I'm working on getting some example datasets together. Mike Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit : On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. ArcGIS 10 FileGDB's right ? Yes real data would be usefull. But it would also be usefull if you (or anyone else) could provide small and freely redistribuable samples (potentially fake data) with different types of geometries (1 feature for each geometry type is enough in theory), column types (integer, single, double, string, date), etc.. so that it can be included in the GDAL/OGR autotest suite. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) Hermann
[gdal-dev] gdaladdo creates very large files in 1.8 but not trunk
This is an informational report only, there are not problems in trunk. Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs totally 80G. gdalbuildvrt mosaic.vrt *.tif Then gdal_translated that to a compressed tif of about 8G gdal_translate mosaic.vrt mosaic_ycbcr_big.tif -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 800 Last step was to add some overviews: gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config BIGTIFF_OVERVIEW YES --config GDAL_CACHEMAX 800 -r average -ro mosaic_ycbcr_big.tif 2 4 8 16 32 64 128 It works (at least in OpenEV it displays quickly like it is using overviews), except the file sizes for the overviews seem odd and too large. The tiles are about 80G, the result of gdal_translate is 8G, the result of gdaladdo, mosaic_ycbcr_big.tif.ovr, is 375G! That was using 1.8.0. I tested on trunk on ubuntu and XP from here, http://vbkto.dyndns.org/sdk/ which produce reasonable results. The ovr is about 3G. A dif of gdalinfo on the .tif and .ovr are the same. (I hope that is not the result of a typo when I initially typed the command. I unfortunately don't have the shell around any more but took the above listed commands from some notes I took.) I have tried making the overviews internal and external with similar results. I also tried making the overviews on the uncompressed files (the vrt) with the same results. Then I made the overviews 1 level at a time and those results seemed reasonable. I didn't find any tickets about this in trac, but don't experience this in trunk so apparently it is fixed. Just reporting in case it is useful. Do you want any other information? Thanks, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
I reviewed this a little further. I was mistaken in my first report, the field RDSRCDATE was created as DATE (as opposed to DateTime) and populated with null. I had mistakenly checked and reported on the field CONST_DATE which is created as an Integer and populated with null. (I don't know if the field is populated in the fgdb.) eadam@lgis0229ubuntu:/usr/local/src/gdal$ ogrinfo --formats ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory Supported Formats: - ESRI Shapefile (read/write) - MapInfo File (read/write) - UK .NTF (readonly) - SDTS (readonly) - TIGER (read/write) ... ... Any suggestions? I've been tracking trunk of gdal for about a year, although always in a simple fashion (no plugins etc). I would not necessarily catch something basic. Based on reading this two sites, http://stackoverflow.com/questions/480764/linux-error-while-loading-shared-libraries-cannot-open-shared-object-file-no-su and http://replay.waybackmachine.org/20090301081221/http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html I fixed this by calling it this way, eadam@lgis0229ubuntu:~$ LD_LIBRARY_PATH=.:/home/eadam/filegdb/dist/lib ogrinfo --formats Now I get eadam@lgis0229ubuntu:~$ LD_LIBRARY_PATH=.:/home/eadam/filegdb/dist/lib ogr2ogr ODF_Lincoln_Roads_v2.shp ~/Desktop/West_Oregon_Roads.gdb ODF_Lincoln_Roads Warning 6: Field RDSRCDATE create as date field, though DateTime requested. Warning 6: Normalized/laundered field name: 'CONSTRUCTED' to 'CONSTRUCTE' Warning 6: Normalized/laundered field name: 'Shape_Length' to 'Shape_Leng' ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 RDSRCDATE has dates in it now. So it looks like this was a DateTime field and got successfully demoted to a date field. Thanks, Eli On 4/12/2011 at 11:47 AM, in message 201104122047.20004.even.roua...@mines-paris.org, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 20:37:06, Smith, Michael ERDC-CRREL-NH a écrit : Even, How do you configure gdal/ogr to build with the linux api? This is a bit involved since there's no ./configure support yet, so I compile it at hand as a plugin Here's the line I use from GDAL root source directory : g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport - Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal - I/home/even/filegdb/dist/include -L/home/even/filegdb/dist/lib - I/home/even/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI You must change the /home/even/filegdb/ paths to where you uncompress the filegdb API And you must define the GDAL_DRIVER_PATH environmenet variable to point to the path where ogr_filegdb.so is I'm working on getting some example datasets together. Mike Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit : On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. ArcGIS 10 FileGDB's right ? Yes real data would be usefull. But it would also be usefull if you (or anyone else) could provide small and freely redistribuable samples (potentially fake data) with different types of geometries (1 feature for each geometry type is enough in theory), column types (integer, single, double, string, date), etc.. so that it can be included in the GDAL/OGR autotest suite. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) Hermann ___ 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 ___ 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
Re: [gdal-dev] gdaladdo creates very large files in 1.8 but not trunk
I'm not aware of any recent change in the GTiff driver that could have solved the issue you've seen. This is a bit surprising. Could you also try with the -stable builds (based on 1.8 branch) from http://vbkto.dyndns.org/sdk/ to compare ? I am trying it with, http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1500-gdal-1-8-mapserver-5-6.zip Although not finished, based on progress so far, it looks to be working properly and on track to create a 3G ovr. That is consistent with trunk. I'll provide more information when it finishes. Eli This is an informational report only, there are not problems in trunk. Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs totally 80G. gdalbuildvrt mosaic.vrt *.tif Then gdal_translated that to a compressed tif of about 8G gdal_translate mosaic.vrt mosaic_ycbcr_big.tif -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 800 Last step was to add some overviews: gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config BIGTIFF_OVERVIEW YES --config GDAL_CACHEMAX 800 -r average -ro mosaic_ycbcr_big.tif 2 4 8 16 32 64 128 It works (at least in OpenEV it displays quickly like it is using overviews), except the file sizes for the overviews seem odd and too large. The tiles are about 80G, the result of gdal_translate is 8G, the result of gdaladdo, mosaic_ycbcr_big.tif.ovr, is 375G! That was using 1.8.0. I tested on trunk on ubuntu and XP from here, http://vbkto.dyndns.org/sdk/ which produce reasonable results. The ovr is about 3G. A dif of gdalinfo on the .tif and .ovr are the same. (I hope that is not the result of a typo when I initially typed the command. I unfortunately don't have the shell around any more but took the above listed commands from some notes I took.) I have tried making the overviews internal and external with similar results. I also tried making the overviews on the uncompressed files (the vrt) with the same results. Then I made the overviews 1 level at a time and those results seemed reasonable. I didn't find any tickets about this in trac, but don't experience this in trunk so apparently it is fixed. Just reporting in case it is useful. Do you want any other information? Thanks, Eli ___ 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] Re: FileGDB OGR driver test
Ragi, I tested the driver on just one FileGDB which included a date field. You stated, Known issues with build / FileGDB driver - (driver issue) blobs and date fields are not handled at all Here is what I did and successfully got the data. The date field was made a double and populated with 0, however, since it says that date fields are not handled, it is nice that the rest of the process still worked on the other fields and the data was exported. ogr2ogr ODF_Lincoln_Roads.shp West_Oregon_Roads.gdb ODF_Lincoln_Roads Warning 6: Field RDSRCDATE create as date field, though DateTime requested. Warning 6: Normalized/laundered field name: 'CONSTRUCTED' to 'CONSTRUCTE' Warning 6: Normalized/laundered field name: 'Shape_Length' to 'Shape_Leng' Warning 1: Row id: 4 col:10 has unhandled col type (11). Setting to NULL. ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 Thanks for the work on this. Eli On 4/13/2011 at 11:13 AM, in message banlktimitsqyjfixfrys05jkeibya+t...@mail.gmail.com, Ragi Burhum r...@burhum.com wrote: Perfect. Thank you Michael. - Ragi Date: Tue, 12 Apr 2011 15:45:25 -0400 From: Smith, Michael ERDC-CRREL-NH michael.sm...@usace.army.mil Subject: Re: [gdal-dev] Re: FileGDB OGR driver test To: Even Rouault even.roua...@mines-paris.org, gdal-dev@lists.osgeo.org Message-ID: c9ca2415.2220d%michael.sm...@usace.army.mil Content-Type: text/plain; charset=ISO-8859-1 I have a test v10 filegdb with points, lines, polygons (all with Z and M but I think the measures aren't populated). There are also some non geometry tables and some relationship classes. Its available at http://12.189.158.78:8081/downloads/test_fgdb.gdb.zip Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers On 4/12/11 2:48 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 20:40:58, Matt Wilkie a écrit : ArcGIS 10 FileGDB's right ? If the api allows for using gdb's from different versions then the test suite should have different versions too. In any case I can make v10 gdb's. No, the FileGDB API only reads v10 gdb's. Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) We are working on a Linux 64-bit release of the File Geodatabase API. It will not release with the 1.0 release of the API, but as a part of a follow on release later this year. Lance Shipman Geodatabase Product Engineer, File Geodatabase esri ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ftp user and password with vsizip/vsicurl
Is it possible to use vsizip and vsicurl on a password protected ftp site? Something like this command with user and password passed somehow: ogrinfo -ro -al -so /vsizip/vsicurl/ftp://example.com/foldername/file.zip/example.shp I rather hopefully tried some switches, -user:user -password:password, which did not work. Thanks for the vsi support, it is awesome! For vsizip/gz/tar, I find this wiki page very useful, http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip I can find all the gdal drivers that support virtual files by following the directions on that page (driver marked with 'v' when running 'gdalinfo --formats'). I tried a similar approach for ogr (ogrinfo --formats and looked for 'v') without learning much. Is there a way to determine virtual file support in ogr? I found that shp is supported by successfully testing it and recalling an IRC mention. Most of what I find for vsicurl is here, http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News Is there somewhere else that I should look for documentation on vsicurl? I gave a shot at adding information to the vsizip wiki page, can someone review it to make sure that I am not spreading false information and correct or delete it if needed? I added to the vsizip page rather than making a different page since vsicurl is often used with vsizip. Currently, the example commands that I put there give an error claiming that the .shx is corrupt. For instance, ogrinfo -ro -al -so /vsicurl/http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/data/poly.shp Any help appreciated, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ftp user and password with vsizip/vsicurl
Even, I've added most of this to the wiki. I've also corrected the urls that were incorrect. http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip#vsicurl-toreadfromHTTPorFTPfilespartialdownloading Thanks, Eli On 4/12/2011 at 11:11 AM, in message 201104122011.20768.even.roua...@mines-paris.org, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 17:26:02, Eli Adam a écrit : Is it possible to use vsizip and vsicurl on a password protected ftp site? Something like this command with user and password passed somehow: ogrinfo -ro -al -so /vsizip/vsicurl/ftp://example.com/foldername/file.zip/example.shp I rather hopefully tried some switches, -user:user -password:password, which did not work. I've just tried with an FTP site and ogrinfo -ro -al -so /vsizip/vsicurl/ftp://user:passw...@example.com/foldername/file.zip/example. shp works Thanks for the vsi support, it is awesome! For vsizip/gz/tar, I find this wiki page very useful, http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip I can find all the gdal drivers that support virtual files by following the directions on that page (driver marked with 'v' when running 'gdalinfo --formats'). I tried a similar approach for ogr (ogrinfo --formats and looked for 'v') without learning much. Is there a way to determine virtual file support in ogr? I found that shp is supported by successfully testing it and recalling an IRC mention. No, there's no easy way of knowing if an OGR driver supports VSI virtual file handlers such as vsizip, vsicurl etc... From a quick grep -r VSILFILE ogr/ogrsf_frmts/, I can see in current trunk (might not be the case for all drivers in GDAL 1.8.0 as a few have been converted since the release), that CSV, PGDUMP (well, this is just write- only), SVG, KML, HTF, DXF, PDS, VRT, GPX, AERONAVFAA, GTM, EDIGEO, SHAPE, OPENAIR, LIBKML, GEORSS, GPSBABEL, BNA, GEOJSON, XPLANE, GMT, GML, SUA and S57 use the VSI virtual file API at least partially. Caution : It doesn't mean that they are all fully vetted to be compatible with it. Most of what I find for vsicurl is here, http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News Is there somewhere else that I should look for documentation on vsicurl? I gave a shot at adding information to the vsizip wiki page, can someone review it to make sure that I am not spreading false information and correct or delete it if needed? I added to the vsizip page rather than making a different page since vsicurl is often used with vsizip. There's some info in the doc of VSIInstallCurlFileHandler() here http://gdal.org/cpl__vsi_8h.html#4f791960f2d86713d16e99e9c0c36258 You might want to add the link to it, like it is done for the other special file handlers in the page. Currently, the example commands that I put there give an error claiming that the .shx is corrupt. For instance, ogrinfo -ro -al -so /vsicurl/http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/data/poly.s hp This was just a bad URL. ogrinfo -ro -al -so /vsicurl/http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp works Any help appreciated, Eli ___ 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] Get pixel values from all bands
Alexander,
Not sure if it meets you situation, but there is a command line utility
with similar functionality, gdallocationinfo,
http://gdal.org/gdallocationinfo.html
HTH, Eli
On 3/16/2011 at 1:21 PM, in message
20110316222128.b943f4e3.alexander.b...@gmail.com, Alexander Bruy
alexander.b...@gmail.com wrote:
Hi all
I work on raster processing application (developed with C++ and Qt).
For reading rasters we use GDAL and it's C++ API.
For one task we need to get pixel values from all raster bands. For
this I get all GDALRasterBands and store them in list. Then in loop
read image row by row and store row from each band in another list.
Here is simplified code
// iterate over image row by row
for ( int row = 0; row ySize; ++row )
{
// read one row from each band and store it in list
for ( int b = 0; b bandCount; ++b )
{
float *scanline;
scanline = (float *) CPLMalloc( sizeof( float ) * xSize );
bands[ i ]-RasterIO( GF_Read, 0, row, xSize, 1, scanline, xSize,
1, GDT_Float32, 0, 0 );
rows[ i ] = scanline;
}
// iterate on pixels in row
for (int col = 0; col ySize; ++col)
{
// get pixel value from bands
float pixel[bandCount];
for ( int r = 0; r bandCount; ++r )
{
// get value in (row, col) from band r
double pixel[r] = rows[ r ][ col ];
}
// do something with this pixel
}
}
Is this correct approach? Or maybe there is another more correct way
to do this?
Also I'm not sure where I should free memory allocated with CPLMalloc().
After reading pixels and before reading next rows or at end when
all rows processed?
I'm not a big C++ programmer, so any help is very appreciated
Thanks
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Many files over the network
I apologize if this question has been posted previously, but I haven't yet found a convenient way to search the archives. Thanks, Kyle Kyle, It took me a while to find how to do that as well. Try nabble, http://osgeo-org.1803224.n2.nabble.com/GDAL-Dev-f2022644.html Bests, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTMzone 12N )
Sumit, Looking at EPSG:26912 on spatial reference, http://spatialreference.org/ref/epsg/26912/ and your longitude coordinates (74-76 East, no less) makes it questionable if 26912 is an appropriate projection. That projection looks valid for western Mexico, and midwestern US/CA. You data looks to be roughly in Asia. I think that error says that it is not in a valid area of the target projection. Bests, Eli On 3/1/2011 at 2:28 PM, in message 1299018481319-6078961.p...@n2.nabble.com, Delirious sumitpande...@gmail.com wrote: I am trying to convert a file in WGS format to Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTM zone 12N ), comman line input is C:\Program Files (x86)\FWTools2.4.7gdalwarp -t_srs EPSG:26912 G:\TestData\dem43m.tif G:\TestData\opt.tif ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds. I am giving above stated error. gdalinfo of the input file is given below Size is 1201, 1201 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (74.9995834,36.0004166) Pixel Size = (0.0008333,-0.0008333) Metadata: TIFFTAG_SOFTWARE=ERDAS IMAGINE TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 74.9995833, 36.0004167) ( 74d59'58.50E, 36d 0'1.50N) Lower Left ( 74.9995833, 34.9995833) ( 74d59'58.50E, 34d59'58.50N) Upper Right ( 76.0004167, 36.0004167) ( 76d 0'1.50E, 36d 0'1.50N) Lower Right ( 76.0004167, 34.9995833) ( 76d 0'1.50E, 34d59'58.50N) Center ( 75.500, 35.500) ( 75d30'0.00E, 35d30'0.00N) Band 1 Block=64x64 Type=Int16, ColorInterp=Gray Am i doing anything wrong? Thanks Sumit Pandey ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 /UTMzone 12N )
Sumit, There are a lot of NAD83 UTM projection zones. You need to chose the proper one. Without learning a fair amount about datums, projections, and the area where you are working, you may be best looking on wikipedia and spatial reference to guess a UTM zone that matches your general area. NAD83 is the North American Datum of 1983, you may want a different datum for your area. A rough guess that may be a decent starting place might be WGS84 UTM 45N. Datums, projections, etc are incredibly complex. USGS gives an overview here, http://egsc.usgs.gov/isb/pubs/MapProjections/projections.html I don't have any advice for any easy or quick way to select a proper datum and projection. If you know someone working with similar data in the same area, ask them. You may be best leaving the data in EPSG:4326, I don't know. HTH, Eli On 3/1/2011 at 3:21 PM, in message 1299021669799-6079096.p...@n2.nabble.com, Delirious sumitpande...@gmail.com wrote: Thanks adam, I am novice to this field. So my question might seem trivial or vague - Even if the data is of asia, cant it be projected in NAD83 UTM 12N. Errors might be high, but it should be convertible. If i want to convert this data in NAD83 datum and UTM projection what should i do? Cheers Sumit Pandey ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_rasterize 1.8.0 options
Marius, I don't know about 1. but possibilities for 2. and 3 below. Hi Everyone, Some of the options (I didn't test all) introduced with version 1.8.0 seem to behave strangely. Here's what I'm doing: 1. gdal_rasterize -burn 0 -i -l mask mask.shp sample.tif works fine but I get the following warning: Warning : the output raster dataset and the input vector layer do not have the same SRS. Results might be incorrect (no on-the-fly reprojection of input data). even though both inputs use the same projection, EPSG:3844. 2. gdal_rasterize -burn 0 -i -a_srs EPSG:3844 -l mask mask.shp sample.tif fails with: '-tr xres yes' or '-ts xsize ysize' is required. 3. gdal_rasterize -burn 0 -i -a_nodata 0 -l mask mask.shp sample.tif fails with: '-tr xres yes' or '-ts xsize ysize' is required. From http://www.gdal.org/gdal_rasterize.html it doesn't seem that -a_srs or -a_nodata would require -tr or -ts. Am I doing something wrong? Does sample.tif exist? If not, the docs say you need to use -tr or -ts, Since GDAL 1.8.0, the target GDAL file can be created by gdal_rasterize. One of -tr or -ts option must be used in that case. I don't know why that error would not also come from 1. Bests, Eli -marius ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Naive warping question
Brian, You could try gdalbuildvrt, then gdalwarp that with -of VRT, then tile it how you like with gdal_translate. I think that gdal_retile.py has some options to do what you want as well. I think that the slivers are probably because the projections have different angles of rotations and pixels may not be exactly square in each projection and may not map from one to the other cleanly. Making a mosiac first (even if virtual) deals with this (or at least pushes it to your edges where you won't notice it. HTH, Eli Brian Hamlin mapl...@light42.com 12/21/2010 12:13 PM Hi All- I have a series of tiffs, georef'd in 4326, which side by side cover 1000 km at latitude 38 California from the coast past the borders I warped them all to 3310 using gdalwarp with default settings.. However, the resulting images appear to leave a sliver between them In other words, they are *not* complete coverage of the area covered in the original tiffs. This is unexpected to me.. Is this expected results? How can I be sure to get complete coverage in the resulting set of re-projected tiffs? thanks -Brian == Brian Hamlin planetwork.net OSGeo California Chapter (415) 717-4462 cell ___ 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] RFC 32 - gdallocationinfo utility
Frank, This is a helpful new utility. I read the documentation and tried it out. Using gdallocationinfo to find the elevation at a given lat/long location seems like a reasonable use. It may be desirable to input and output an ogr layer rather than a single point. For instance, what are the elevations at these points in this shapefile? I tried to approach that problem by putting the coordinates into a file with ogrinfo and then use that file as an --optfile for the x y. That didn't work the way that I tried it. Can an --optfile be used for the x y input? ogrinfo town.shp town | grep 'POINT' | sed 's/ POINT (//' | sed 's/)//' xyinput2.txt head xyinput2.txt 7350538.701077490113676 371057.403368594241329 7388905.153187953867018 357147.769300847954582 7346377.449287764728069 409114.138115067325998 gdallocationinfo -s_srs EPSG:2913 townraster.tif --optfile xyinput2.txt Usage: gdallocationinfo [--help-general] [-xml] [-lifonly] [-valonly] [-b band]* [-s_srs srs_def] [-geoloc] [-wgs84] srcfile x y What would be the proper approach to the above hypothetical problem? Is there an effective way to have an ogr input for gdallocaitoninfo? Perhaps -input_file_list my_liste.txt for the x y similar to gdalbuildvrt? It looks like -s_srs applies to the x y input. -s_srs sometimes, i.e. gdalwarp, applies to the srcfile. Is -wgs84 equivalent to -s_srs EPSG:4326? These were my initial thoughts I hope that some of them may be helpful. Thanks for the new utility, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
