Re: [gdal-dev] gdal2tiles custom tms configuration not found

[Andreas Neumann via gdal-dev]

Hi Even,

Thank you - that explains it. I will probably switch to some other tools 
then - maybe MapProxy. I wanted to use this custom tms configuration 
from Swisstopo - to stay compatible with their web services.


Thank you for adding a better error output!

Andreas

On 2024-01-19 13:08, Even Rouault wrote:


Andreas,

the reason is that the resolution of some consecutive levels in your 
custom TMS files is not varying by a factor of 2, which gdal2tiles 
doesn't support at the moment (debug message just added in master to 
help diagnose)


Even

Le 19/01/2024 à 11:36, Andreas Neumann via gdal-dev a écrit :


Hi,

I would like to use gdal2tiles with a custom tms profile file. I 
prepared the json file attached in this mail and put this json file in 
the /usr/share/gdal folder, there there are already other such files, 
e.g. from New Zealand or Antartica.


However, when I try to use this custon tms config, gdal2tiles tells me 
it can't find this profile. Here is my command I used:


gdal2tiles.py -p 2056_28 -z 16 -w openlayers -t "Swiss Hillshading 
Grayscale" -r cubic -s EPSG:2056 -a 0.0 -e -n 
lv_16_switzerland_hillshading_small-scale_swissalti3d-srtm_100m_jpeg.tif 
tiles


Do I need to register the custom TMS config json file somewhere in 
addition to copying it to the /usr/share/gdal directory?


Thank you for your help!

Andreas

___
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] gdal2tiles custom tms configuration not found

[Andreas Neumann via gdal-dev]

Hi,

Just found 
https://github.com/OSGeo/gdal/blob/master/swig/python/gdal-utils/osgeo_utils/gdal2tiles.py#L272 
where it seems to look for all files following the naming scheme 
"tms_*.json". Therefore I don't know why my custom tms configuration 
files is not found - any ideas?


My custom tms json file also has an identifier set to '2056_28'.

Here is the error message I get:
gdal2tiles.py: error: option -p: invalid choice: '2056_28' (choose from 
'mercator', 'geodetic', 'raster', 'LINZAntarticaMapTilegrid', 'APSTILE')


Andreas

On 2024-01-19 11:36, Andreas Neumann via gdal-dev wrote:


Hi,

I would like to use gdal2tiles with a custom tms profile file. I 
prepared the json file attached in this mail and put this json file in 
the /usr/share/gdal folder, there there are already other such files, 
e.g. from New Zealand or Antartica.


However, when I try to use this custon tms config, gdal2tiles tells me 
it can't find this profile. Here is my command I used:


gdal2tiles.py -p 2056_28 -z 16 -w openlayers -t "Swiss Hillshading 
Grayscale" -r cubic -s EPSG:2056 -a 0.0 -e -n 
lv_16_switzerland_hillshading_small-scale_swissalti3d-srtm_100m_jpeg.tif 
tiles


Do I need to register the custom TMS config json file somewhere in 
addition to copying it to the /usr/share/gdal directory?


Thank you for your help!

Andreas
___
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

[gdal-dev] gdal2tiles custom tms configuration not found

[Andreas Neumann via gdal-dev]

Hi,

I would like to use gdal2tiles with a custom tms profile file. I 
prepared the json file attached in this mail and put this json file in 
the /usr/share/gdal folder, there there are already other such files, 
e.g. from New Zealand or Antartica.


However, when I try to use this custon tms config, gdal2tiles tells me 
it can't find this profile. Here is my command I used:


gdal2tiles.py -p 2056_28 -z 16 -w openlayers -t "Swiss Hillshading 
Grayscale" -r cubic -s EPSG:2056 -a 0.0 -e -n 
lv_16_switzerland_hillshading_small-scale_swissalti3d-srtm_100m_jpeg.tif 
tiles


Do I need to register the custom TMS config json file somewhere in 
addition to copying it to the /usr/share/gdal directory?


Thank you for your help!

Andreas

tms_Swisstopo_2056_28.json
Description: application/json
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogrinfo , ogr2ogr file size limits

[Andreas Neumann]

Hi,

Most likely, Frando is talking about the "Interlis" format - a format 
common in Switzerland (and also Colombia, by export from Switzerland).


see https://gdal.org/drivers/vector/ili.html

Since this involves Java ili2c, you should set the corresponding XmX 
memory setting for the Java compiler, which is memory limited by 
default.


There is also an alternative XTF import export tool available, called 
il2db (ili2pg, ili2ora, ili2gpkg, ili2fgdb). See 
https://github.com/claeis/ili2db/blob/master/docs/ili2db.rst


I generally recommend to use ili2db versions rather than the ogr 
interlis drive. The ili2db is way more tested and flexible with loads of 
options.


Greetings,

Andreas

On 2022-05-17 11:53, Joaquim Manuel Freire Luís wrote:


xtf is the extension by a format of sidescan sonar data.

This one was picked randomly from a google search

https://www.usna.edu/Users/oceano/pguth/md_help/html/sidescan.htm

From: gdal-dev  On Behalf Of Even 
Rouault

Sent: Tuesday, May 17, 2022 10:43 AM
To: Gonzalez Velasquez, Frando Alexis ; 
gdal-dev@lists.osgeo.org

Cc: Serrano Granados, Yency 
Subject: Re: [gdal-dev] Ogrinfo , ogr2ogr file size limits

Frando,

The .xtf extension doens't ring a bell to me. Which OGR driver 
recognizes such file ? (remove the -q option and look at the beginning 
of the report of ogrinfo), and what is your GDAL version ?


Most OGR drivers work in streaming mode and can handle arbitrary big 
files, but a few ones have no other choice than ingesting the whole 
file, in which case there's no workaround apart splitting the file with 
other tools or buy more RAM


Even

Le 17/05/2022 à 04:21, Gonzalez Velasquez, Frando Alexis a écrit :


Hi dev team!

I am writing to inquire about big files problem,

We are using the ogrinfo and ogr2ogr executables over small files with 
success (1 gb max)  but with 10 gb files we are experiencing memory 
problems and and it does not work, is there a file size limit? And if 
there is a size limit, is there any strategy to handle this problema 
and process big files with success ?


For example:

_ogrinfo -q -so C:\\tmp\\file.xtf _

When file is 1Gb success ; but when  the file is 10gb size the process 
fails.


Any advice would be appreciated, thanks.

FRANDO GONZÁLEZ

Senior Systems Engineer

fagonzal...@indracompany.com

Calle 93 16 25

Bogotá, Colombia

T +57 1 646 36 00

M +57 3006604908

minsait.com [1]

indracompany.com [2]

-

Este correo electrónico y, en su caso, cualquier fichero anexo al 
mismo, contiene información de carácter confidencial exclusivamente 
dirigida a su destinatario o destinatarios. Si no es vd. el 
destinatario indicado, queda notificado que la lectura, utilización, 
divulgación y/o copia sin autorización está prohibida en virtud de la 
legislación vigente. En el caso de haber recibido este correo 
electrónico por error, se ruega notificar inmediatamente esta 
circunstancia mediante reenvío a la dirección electrónica del 
remitente.

Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) 
confidential information that is exclusively addressed to its 
recipient(s). If you are not the indicated recipient, you are informed 
that reading, using, disseminating and/or copying it without 
authorisation is forbidden in accordance with the legislation in 
effect. If you have received this email by mistake, please immediately 
notify the sender of the situation by resending it to their email 
address.

Avoid printing this message if it is not absolutely necessary.

___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev


--

http://www.spatialys.com

My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev




Links:
--
[1] 
https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.minsait.com%2F&data=04%7C01%7Cfagonzalezv%40indracompany.com%7C6c419c97a7134841c0da08d9f7ce4282%7C7808e00514894374954bd3b08f193920%7C0%7C0%7C637813287514711623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0Jr%2BkI3f3Uh3g%2FG5C5yElQX9pHauhEi9ds6w%2FPOxLtM%3D&reserved=0
[2] 
https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.indracompany.com%2F&data=04%7C01%7Cfagonzalezv%40indracompany.com%7C6c419c97a7134841c0da08d9f7ce4282%7C7808e00514894374954bd3b08f193920%7C0%7C0%7C637813287514711623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W2xsw4RMlZ8TUymKMTE5zqosvKN2LV5QhwvGmAxgZM0%3D&reserved=0___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WEBP in GEOTIFF

[Andreas Neumann]

Hi Thomas,

Interesting - thanks for the hint about turbo-jpeg.

I found out that my gdal is linked against libjpeg.so.8 and not against 
libturbojpeg.so.0 which is also present on my system.


Would I have to tell gdal to compile against libturbojpeg with the 
--with-jpeg= flag in order to benefit from turbo-jpeg?


And yes, the mask thing is what I was struggling with JPEG compression 
and RGB images, but I got the mask to work by using the following 
gdal_translate command:


|gdal_translate -b 1 -b 2 -b 3 -b mask -of COG --config 
GDAL_DISABLE_READDIR_ON_OPEN TRUE\ -co COMPRESS=JPEG -co BIGTIFF=YES -co 
NUM_THREADS=4 -a_srs EPSG:2056\ infile.vrt outfile.tif|


Thanks and greetings,

Andreas

Am 09.10.20 um 17:53 schrieb thomas bonfort:

Andreas,
The size gains compared to JPEG are marginal, at the cost of 
noticeably higher compression and decompression times (especially 
compared to the optimized turbo jpeg library). WEBP does however 
support an alpha channel which can be desirable, as it avoids having 
to add a mask IFD to the TIFF.

Regards,
Thomas

On Fri, Oct 9, 2020 at 4:30 PM Andreas Neumann <mailto:a.neum...@carto.net>> wrote:


Thanks Thomas,

Yes, compiling it with libtiff=internal and libgeotiff=internal
did the trick - thanks for the hint!

Do you recommending using webp instead of jpeg inside GTIFF or
COG? It seems like the WEBP compression produces smaller file
sizes than JPEG, but how does it look speed-wise regarding
decompression?

Thanks,

Andreas

On 2020-10-09 15:33, thomas bonfort wrote:


You might need to compile with gdal's internal libtiff so that
webp-in-tif support is enabled (i.e. the system libtiff might not
have webp support). Also note you should probably be adding "-co
TILED=YES" to your translate command.

On Fri, Oct 9, 2020 at 3:07 PM Andreas Neumann
mailto:a.neum...@carto.net>> wrote:

Hi,

I am using a self-compiled GDAL 3.1.2 version and try to
create a GTIFF file with COMPRESS=WEBP

libwebp-devel and other webp automatic dependencies are
installed on this ubuntu 18.04 machine. I could also compile
against libwebp

However, when running gdal_translate like

gdal_translate -b 1 -b 2 -b 3 -b mask -of GTIFF -co
COMPRESS=WEBP -co PHOTOMETRIC=YCBCR -co BLOCKXSIZE=512 -co
BLOCKYSIZE=512 -co BIGTIFF=YES -co NUM_THREADS=4 -a_srs
EPSG:2056 -projwin 2599700 1226200 2602200 1224650
ch.swisstopo.orthofoto_2018.rgb.vrt test_webp_ycbcr.tif

I get the following error output:

Input file size is 53, 48
Warning 6: 'WEBP' is an unexpected value for COMPRESS
creation option of type string-select.
ERROR 1: Cannot create TIFF file due to missing codec for WEBP.

Any idea what might be missing in my installation - where do
I get this missing codec for WEBP?

Thanks,

Andreas


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto: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] WEBP in GEOTIFF

[Andreas Neumann]

Thanks Thomas, 


Yes, compiling it with libtiff=internal and libgeotiff=internal did the
trick - thanks for the hint! 


Do you recommending using webp instead of jpeg inside GTIFF or COG? It
seems like the WEBP compression produces smaller file sizes than JPEG,
but how does it look speed-wise regarding decompression? 

Thanks, 

Andreas 


On 2020-10-09 15:33, thomas bonfort wrote:

You might need to compile with gdal's internal libtiff so that webp-in-tif support is enabled (i.e. the system libtiff might not have webp support). Also note you should probably be adding "-co TILED=YES" to your translate command. 

On Fri, Oct 9, 2020 at 3:07 PM Andreas Neumann  wrote: 

Hi, 

I am using a self-compiled GDAL 3.1.2 version and try to create a GTIFF file with COMPRESS=WEBP 

libwebp-devel and other webp automatic dependencies are installed on this ubuntu 18.04 machine. I could also compile against libwebp 

However, when running gdal_translate like 


gdal_translate -b 1 -b 2 -b 3 -b mask -of GTIFF -co COMPRESS=WEBP -co 
PHOTOMETRIC=YCBCR -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co BIGTIFF=YES -co 
NUM_THREADS=4 -a_srs EPSG:2056 -projwin 2599700 1226200 2602200 1224650 
ch.swisstopo.orthofoto_2018.rgb.vrt test_webp_ycbcr.tif

I get the following error output: 

Input file size is 53, 48 
Warning 6: 'WEBP' is an unexpected value for COMPRESS creation option of type string-select. 
ERROR 1: Cannot create TIFF file due to missing codec for WEBP.


Any idea what might be missing in my installation - where do I get this missing codec for WEBP? 

Thanks, 

Andreas 


___
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

[gdal-dev] WEBP in GEOTIFF

[Andreas Neumann]

Hi, 


I am using a self-compiled GDAL 3.1.2 version and try to create a GTIFF
file with COMPRESS=WEBP 


libwebp-devel and other webp automatic dependencies are installed on
this ubuntu 18.04 machine. I could also compile against libwebp 

However, when running gdal_translate like 


gdal_translate -b 1 -b 2 -b 3 -b mask -of GTIFF -co COMPRESS=WEBP -co
PHOTOMETRIC=YCBCR -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co BIGTIFF=YES
-co NUM_THREADS=4 -a_srs EPSG:2056 -projwin 2599700 1226200 2602200
1224650 ch.swisstopo.orthofoto_2018.rgb.vrt test_webp_ycbcr.tif

I get the following error output: 

Input file size is 53, 48 
Warning 6: 'WEBP' is an unexpected value for COMPRESS creation option of
type string-select. 
ERROR 1: Cannot create TIFF file due to missing codec for WEBP.


Any idea what might be missing in my installation - where do I get this
missing codec for WEBP? 

Thanks, 


Andreas___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Discussing DTM compression in GeoTIFF

[Andreas Neumann]

Hi, 


I was reading through
https://kokoalberti.com/articles/geotiff-compression-optimization-guide/
(very interesting article) and I am wondering about how to interpret
read-speed vs compression. With this article I learned about the
relatively new zstd compression and LERC, which is esp. interesting for
LIDAR/DTM data in float32. 


In general, when you compress more, the read-speed decreases. So an
uncompressed file would read very fast. But isn't this gain in read
speed at the expense that you have to read a substantially higher amount
of data when you use uncompressed or low-compressed data? 


E.g. in the table
https://kokoalberti.com/articles/geotiff-compression-optimization-guide/read_results.png


when you read a float32 dtm with zstd compression, predictor 3 and
zstd_level 9, it shows a substantially lower read rate compared to
predictor 1 (not optimized for float32). But given that predictor 3
compresses substantially better than predictor 1 for float32, isn't the
read-rate "overall" just as good with predictor 3? 


Formulating my question different: isn't the read-rate at
https://kokoalberti.com/articles/geotiff-compression-optimization-guide/read_results.png
a bit distorted by the fact that higher-compression means that you also
have to read substantially smaller file sizes? Shouldn't this table with
the read-rate be kind of "normalized" with the file sizes it has to read
for exactly the same data? 

Currently, it just lists MB/CPU-sec. 

Thanks for the discussion, 


Andreas___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] self-compiled gdal linking to old already-remove proj libs

[Andreas Neumann]

Hi,

Thank you both Jeff and Even.

Yes, apparently libspatialite was also self-compiled. I can renew that. 
That was the one linking against non-existant old libproj.


For libgeotiff I used the packaged one, which links against 
/usr/lib/x86_64-linux-gnu/libproj.so.15


Is it a problem if libgeotiff links against a different libproj than 
gdal? Should I also self-compile libgeotiff?


Thanks for your help! It helps me to solve the compile and link issues.

Andreas

Am 16.05.20 um 16:12 schrieb Jeff McKenna:

Hi Andreas,

I have been in your exact situation before.  What's happening is that 
a GDAL dependency lib is still pointing to the old libproj version. 
Please check:


 ldd /usr/local/lib/libgdal.so | grep geotiff

    and then ldd to the exact path of the geotiff lib, and look at 
which libproj is linked to


and do the same for spatialite:

  ldd /usr/local/lib/libgdal.so | grep spatialite

 and then ldd to the exact path of the spatialite lib, and look at 
which libproj is linked to


I bet that is what happening in your case also.  If I am correct, then 
you have to recompile those libraries and point to PROJ in /usr/local/


Cheers from across the ocean.

-jeff



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] self-compiled gdal linking to old already-remove proj libs

[Andreas Neumann]

Hi,

After my upgrade of Ubuntu 18.04 to 20.04 I am also renewing all my 
self-compiled "geo" libraries, such as proj, geos and gdal.


I removed old proj libs in /usr/local/lib then compiled and installed 
the  newest proj 7.0.1.


But now I am struggling with gdal - it always tries to link to old, 
already removed libproj versions. When I do


ldd /usr/local/lib/libgdal.so | grep proj

I get

    libproj.so.19 => /usr/local/lib/libproj.so.19 (0x7fbaff612000)
    libproj.so.15 => /usr/lib/x86_64-linux-gnu/libproj.so.15 
(0x7fbafd84e000)

    libproj.so.12 => not found

The libproj.so.12 was removed by me, libproj.so.19 and libproj.so.15 
probably came through some Ubuntu dependency.


How I can I tell the gdal configuration not to link to the already 
removed libproj.so.12 ? And maybe also ignore the libproj.so.15 version?


Thanks for any help!

Andreas

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Refreshing GDAL's logo

[Andreas Neumann]

Hi Mathieu, 

Thanks for working on this. I added my comment on github. 


I do like the logo a lot - my only problem is that I personally, would
associate this particular logo draft more with "proj" than with "gdal". 


To me it represents a compass (Zirkel in german) - and that was in the
pre-computer age more used to do projections than file formats. 


I guess the earth shape is fine, but maybe the compass could be styled
in a way to make it look more like a satellite? E.g. it could have a
smaller angle/fov than the current version that covers the whole earth? 

Just some thoughts - thanks again for working on it. 

Andreas 


On 2019-12-19 10:41, Mathieu Pellerin wrote:


Greetings all,

As some of you might have spotted on GDAL's github account, I have spent some 
time coming up with a refreshed GDAL logo proposal.

The draft's second iteration can be seen here: 
https://github.com/OSGeo/gdal/issues/2117 - thanks to Even's initial comment on 
the first iteration, the second draft looks great! :)

The proposed draft logo is IMHO a nice modernized evolution from GDAL's current 
logo: a simplified representation of earth (the curved green line) under a 
simplified satellite (or compass) floating over it.

IMHO, the logo professionalizes GDAL's first look when someone lands on www.gdal.org [1], on wikipedia's gdal page, etc. As superficial as first impressions are, it remains important. 


On top of the arguably subjective "looking better" argument, it has several 
objective benefits:

- It nicely scales down to a 32px icon size quite nicely (see examples provided 
in the github issue linked to above)

- Being simple and in vector format, it makes it much easier to come up with side 
products, i.e. the "mug test" attached in the gitthub issue ;) this logo would 
likely stand well as a round sticker, printed on a shirt, etc.  which is always useful 
during hackfests.

Thoughts? 


Mathieu

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev




Links:
--
[1] http://www.gdal.org___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] (Geo)PDF information missing from online list of vector drivers?

[Andreas Neumann]

Hi Even, 

Thank you! And sorry for being annoying  ... 

Andreas 


On 2019-11-20 14:47, Even Rouault wrote:


Are there technical issues or other complications that keep us from
listing it as both vector and raster driver?


Just did it: https://gdal.org/drivers/vector/pdf.html___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] (Geo)PDF information missing from online list of vector drivers?

[Andreas Neumann]

Hi Even, 


Yes, PDF is mainly a presentation format. But it is also very much a
vector format. 


Are there technical issues or other complications that keep us from
listing it as both vector and raster driver? Geopackage is also a hybrid
format and is listed in both. 

Thanks, 

Andreas 


On 2019-11-20 11:04, Even Rouault wrote:

On mercredi 20 novembre 2019 09:35:48 CET Andreas Neumann wrote: 


Hi,

Ah - found it under the raster formats:

https://gdal.org/drivers/raster/pdf.html?highlight=pdf

Shouldn't it also be listed under the vector formats? It is more useful
as a vector format - isn't it?


Well PDF is mostly a presentation format. Very much about rendering. Mixes 
raster, text, vector content, and many other things. So the more reliable way 
of exposing it from GDAL point of view is a raster. The vector side of the PDF 
can extract *some* things, but it is lossy.


Even___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] PDF: configure option --enable-pdf-plugin

[Andreas Neumann]

Hi Even, 


Thanks for the clarification. In that case I don't need to build it as a
plugin, since this build will only end up on my own local machine. 

Andreas 


On 2019-11-20 11:08, Even Rouault wrote:


Andreas,


I wonder what exactly the build option "--enable-pdf-plugin enable PDF
driver as a plugin (included in libgdal by default)" means?


Plugin here means as a separate .so/.dll : gdal_PDF.so/dll
Mostly for licensing concerns if using the Poppler backend since Poppler is 
subject to the GPL. So you can make a libgdal build mostly subject to X/MIT or 
similar licenses, and in case you need it, use a gdal_PDF plugin subject to 
GPL



How does this relate to the other options of building against
poppler/podofo/pdfium ?


It is orthogonal to the poppler/podofo/pdfium backend(s) used.
For the pdfium backend, which is a bit involved to build (pdfium actually), 
there were also issues with symbol clashes between embedded libraries in 
pdfium and others used by GDAL, and making a plugin instead of linking in core 
GDAL library seemed to "solve" (workaround) issues. Was at least true on Linux 
with pdfium of a few years ago. I don't remember having had such issues with 
the recent upgrade I did in GDAL master.


Even___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] PDF: configure option --enable-pdf-plugin

[Andreas Neumann]

Hi, 


I wonder what exactly the build option "--enable-pdf-plugin enable PDF
driver as a plugin (included in libgdal by default)" means?

How does this relate to the other options of building against
poppler/podofo/pdfium ? 

Thank you very much if you have more information, 


Andreas___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] (Geo)PDF information missing from online list of vector drivers?

[Andreas Neumann]

Hi, 

Ah - found it under the raster formats: 

https://gdal.org/drivers/raster/pdf.html?highlight=pdf 


Shouldn't it also be listed under the vector formats? It is more useful
as a vector format - isn't it? 

Andreas 


On 2019-11-20 09:34, Andreas Neumann wrote:

Hi, 

I wonder why in the list of available vector drivers at https://gdal.org/drivers/vector/index.html there is no mention of PDF / GeoPDF / GeospatialPDF. Didn't we have an entry for these formats in the past? 

Thanks, 

Andreas 
___

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

[gdal-dev] (Geo)PDF information missing from online list of vector drivers?

[Andreas Neumann]

Hi, 


I wonder why in the list of available vector drivers at
https://gdal.org/drivers/vector/index.html there is no mention of PDF /
GeoPDF / GeospatialPDF. Didn't we have an entry for these formats in the
past? 

Thanks, 


Andreas___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compile problems gdal3.0.2 against proj6

[Andreas Neumann]

Hi all, 


The trick explained at
https://trac.osgeo.org/gdal/wiki/BuildingOnUnixGDAL25dev 

seems to have solved my issue. 

Thanks a lot for the hint, 

Andreas 


On 2019-11-19 14:28, Even Rouault wrote:


Andreas,


So this seems like it links to the old version of proj. Why is using
this one if I specified "--with-proj=/usr/local" ?


GDAL build system doesn't use rpath mechanism for linking, so if there are 
several libproj.so in the path used for linking it will use the first or last 
one, I never remember :-).
Anyway, even if you manage to build, you're bound to run into runtime problems 
if you intend to link GDAL against PROJ 6 and spatialite built against an 
older PROJ.


So 2 ways:
- uninstall the proj development package, and build spatialite against proj6 
too

- or use the trick at https://trac.osgeo.org/gdal/wiki/BuildingOnUnixGDAL25dev

Even___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compile problems gdal3.0.2 against proj6

[Andreas Neumann]

Hi Even, 


Yes - you are right. Other gdal library dependencies still link to the
old version. 


I will the trick at
https://trac.osgeo.org/gdal/wiki/BuildingOnUnixGDAL25dev first, before I
try the harder way to recompile all other packages. 

Thanks, 

Andreas 


On 2019-11-19 14:28, Even Rouault wrote:


Andreas,


So this seems like it links to the old version of proj. Why is using
this one if I specified "--with-proj=/usr/local" ?


GDAL build system doesn't use rpath mechanism for linking, so if there are 
several libproj.so in the path used for linking it will use the first or last 
one, I never remember :-).
Anyway, even if you manage to build, you're bound to run into runtime problems 
if you intend to link GDAL against PROJ 6 and spatialite built against an 
older PROJ.


So 2 ways:
- uninstall the proj development package, and build spatialite against proj6 
too

- or use the trick at https://trac.osgeo.org/gdal/wiki/BuildingOnUnixGDAL25dev

Even___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compile problems gdal3.0.2 against proj6

[Andreas Neumann]

Hi, 


Hm - setting the LD_LIBRARY_PATH variable also didn't help. ldd still
says that it links to the old proj. 

Still the same error message. 


I did a "make clean" to make sure no old stuff is around from previous
attempts. Do I really have to purge the old proj version? Then several
other of the packages on my machine would fail to work ... 

Andreas 


On 2019-11-19 14:15, Andreas Neumann wrote:

Hi, 

Thanks for your reply. 

Here is the output of configure: 

-- 

user@machine:~/dev/gdal-3.0.2$ ./configure --with-python=python3 --with-proj=/usr/local --with-pg=yes --with-spatialite=yes | grep proj 
/bin/bash: ./config.rpath: No such file or directory 
checking for PROJ >= 6 library... checking for proj_create_from_wkt in -lproj... yes 
configure: proj.h found 
config.status: WARNING:  'GDALmake.opt.in' seems to ignore the --datarootdir setting


-- 

And here the output of ldd: 

-- 

user@machine:~/dev/gdal-3.0.2$ ldd .libs/libgdal.so | grep proj 
libproj.so.12 => /usr/lib/x86_64-linux-gnu/libproj.so.12 (0x7f72525a5000)


- 

So this seems like it links to the old version of proj. Why is using this one if I specified "--with-proj=/usr/local" ? 

The env var LD_LIBRARY_PATH is not set on my machine. 

Maybe setting one and set /usr/local as the preferred path would solve my problem. I'll try ... 

Thanks, 

Andreas 

On 2019-11-19 14:01, Mateusz Loskot wrote: 
On Tue, 19 Nov 2019 at 13:41, Andreas Neumann  wrote: I am trying to compile gdal3.0.2 against proj6 - but have problems.


Proj6 compile worked fine and I installed in /usr/local

The configure command for gdal is:

./configure --with-python=python3 --with-proj=/usr/local --with-pg=yes 
--with-spatialite=yes
[...]
/bin/bash /home/bjsvwneu/dev/gdal-3.0.2/libtool --mode=link --silent g++  
gdalinfo_bin.lo  /home/bjsvwneu/dev/gdal-3.0.2/libgdal.la  -o gdalinfo
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to `proj_alter_name' 
Try


https://lists.osgeo.org/pipermail/gdal-dev/2019-May/050184.html
https://lists.osgeo.org/pipermail/gdal-dev/2019-May/050189.html

Best regards,


___
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] Compile problems gdal3.0.2 against proj6

[Andreas Neumann]

Hi, 

Thanks for your reply. 

Here is the output of configure: 

-- 


user@machine:~/dev/gdal-3.0.2$ ./configure --with-python=python3
--with-proj=/usr/local --with-pg=yes --with-spatialite=yes | grep proj 
/bin/bash: ./config.rpath: No such file or directory 
checking for PROJ >= 6 library... checking for proj_create_from_wkt in
-lproj... yes 
configure: proj.h found 
config.status: WARNING:  'GDALmake.opt.in' seems to ignore the

--datarootdir setting

-- 

And here the output of ldd: 

-- 

user@machine:~/dev/gdal-3.0.2$ ldd .libs/libgdal.so | grep proj 
  libproj.so.12 => /usr/lib/x86_64-linux-gnu/libproj.so.12

(0x7f72525a5000)

- 


So this seems like it links to the old version of proj. Why is using
this one if I specified "--with-proj=/usr/local" ? 

The env var LD_LIBRARY_PATH is not set on my machine. 


Maybe setting one and set /usr/local as the preferred path would solve
my problem. I'll try ... 

Thanks, 

Andreas 


On 2019-11-19 14:01, Mateusz Loskot wrote:

On Tue, 19 Nov 2019 at 13:41, Andreas Neumann  wrote: 


I am trying to compile gdal3.0.2 against proj6 - but have problems.

Proj6 compile worked fine and I installed in /usr/local

The configure command for gdal is:

./configure --with-python=python3 --with-proj=/usr/local --with-pg=yes 
--with-spatialite=yes
[...]
/bin/bash /home/bjsvwneu/dev/gdal-3.0.2/libtool --mode=link --silent g++  
gdalinfo_bin.lo  /home/bjsvwneu/dev/gdal-3.0.2/libgdal.la  -o gdalinfo
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to 
`proj_alter_name'


Try

https://lists.osgeo.org/pipermail/gdal-dev/2019-May/050184.html
https://lists.osgeo.org/pipermail/gdal-dev/2019-May/050189.html

Best regards,___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Compile problems gdal3.0.2 against proj6

[Andreas Neumann]

Hi, 

I am trying to compile gdal3.0.2 against proj6 - but have problems. 

Proj6 compile worked fine and I installed in /usr/local 

The configure command for gdal is: 


./configure --with-python=python3 --with-proj=/usr/local --with-pg=yes
--with-spatialite=yes

The last part of the compile output is: 

 


/bin/bash /home/bjsvwneu/dev/gdal-3.0.2/libtool --mode=compile --silent
--tag=CXX g++ -I/home/bjsvwneu/dev/gdal-3.0.2/port
-I/home/bjsvwneu/dev/gdal-3.0.2/gcore
-I/home/bjsvwneu/dev/gdal-3.0.2/alg -I/home/bjsvwneu/dev/gdal-3.0.2/ogr
-I/home/bjsvwneu/dev/gdal-3.0.2/ogr/og
rsf_frmts -I/home/bjsvwneu/dev/gdal-3.0.2/gnm
-I/home/bjsvwneu/dev/gdal-3.0.2/apps -DHAVE_AVX_AT_COMPILE_TIME
-DHAVE_SSSE3_AT_COMPILE_TIME -DHAVE_SSE_AT_COMPILE_TIME -g -O2  -Wall
-Wextra -Winit-self -Wunused-parameter -Wformat -Werror=format-security
-Wno-format-nonlite
ral -Wlogical-op -Wshadow -Werror=vla -Wdate-time -Wnull-dereference
-Wduplicated-cond -Wfloat-conversion -Wmissing-declarations
-Wnon-virtual-dtor -Woverloaded-virtual -fno-operator-names
-Wzero-as-null-pointer-constant -Wsuggest-override
-Wimplicit-fallthrough  -I/home
/bjsvwneu/dev/gdal-3.0.2/frmts/vrt -DGNM_ENABLED
-I/home/bjsvwneu/dev/gdal-3.0.2/port -I/usr/include/openjpeg-2.3
-I/usr/include  -DGDAL_COMPILATION -DHAVE_XERCES -I/usr/include
-I/usr/include/xercesc -I/home/bjsvwneu/dev/gdal-3.0.2/port
-I/usr/include/openjpeg-2.3 -I/us
r/include  -DGDAL_COMPILATION -I/usr/include/json-c
-I/home/bjsvwneu/dev/gdal-3.0.2/ogr/ogrsf_frmts/geojson
-I/home/bjsvwneu/dev/gdal-3.0.2/ogr/ogrsf_frmts/generic
-I/home/bjsvwneu/dev/gdal-3.0.2/gnm -DHAVE_GEOS=1 -I/usr/include -c -o
gdalinfo_bin.lo gdalinfo_bin.cpp 
/home/bjsvwneu/dev/gdal-3.0.2/libtool: line 1765: warning: setlocale:
LC_COLLATE: cannot change locale (de_CH.UTF-8) 
/home/bjsvwneu/dev/gdal-3.0.2/libtool: line 1765: warning: setlocale:
LC_COLLATE: cannot change locale (de_CH.UTF-8) 
/bin/bash /home/bjsvwneu/dev/gdal-3.0.2/libtool --mode=link --silent g++
gdalinfo_bin.lo  /home/bjsvwneu/dev/gdal-3.0.2/libgdal.la  -o gdalinfo 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_alter_name' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_eckert_i' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_miller_cylindrical' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_trans_generic' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_oblique_stereographic' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_wagner_i' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_crs_get_geodetic_crs' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_as_wkt' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_projected_crs' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_get_area_of_use' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_compound_crs' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to

`proj_create_conversion_hotine_oblique_mercator_two_point_natural_origin'

/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_grid_info' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_transverse_mercator' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_cs_get_type' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_errno_string' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_utm' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_info' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_eckert_iii' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_equidistant_conic' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_coordoperation_get_method_info' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_mercator_variant_a' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_get_non_deprecated' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_international_map_world_polyconic' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_azimuthal_equidistant' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_crs_create_bound_crs_to_WGS84' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined reference to
`proj_create_conversion_geostationary_satellite_sweep_y' 
/home/bjsvwneu/dev/gdal-3.0.2/.libs/libgdal.so: undefined r

Re: [gdal-dev] ogr2ogr PDF

[Andreas Neumann]

Hi Paul, 

As usual, there are several ways: 


1. You can either create a new attribute called "OGR_STYLE" (see section
2.8 in the spec) that contains the style definition (see chapter 2 in
the spec) 


2. or you create an external .ofs (OGR feature style side-file) as
described in section 2.7 of the spec 


3. or you use the OGR support Classes as described in chapter 3 of the
spec. 

All information is in the spec, incl. some examples. 


I would probably use options 1 or 2 in your case. Option one can be done
in an SQL-Select query, where you create the OGR_STYLE attribute on the
fly with your query. 

Greetings, 

Andreas 


On 2019-11-11 08:45, paul.m...@lfv.se wrote:





Thanks Andreas, 

Yes, I would like to automate it. I have read the page you suggested but I don't understand how to implement it with ogr2ogr. 

Kind regards, 

Paul 

Från: Andreas Neumann [mailto:a.neum...@carto.net] 
Skickat: den 11 november 2019 08:35

Till: Malm, Paul (Operations AIM)
Kopia: gdal-dev@lists.osgeo.org
Ämne: Re: [gdal-dev] ogr2ogr PDF 

Hi Paul, 

ogr2ogr usually doesn't care much about styling, unless you use ogr feature styles: 

https://svn.osgeo.org/gdal/trunk/gdal/ogr/ogr_feature_style.html 

Or you use QGIS 3.10* which has a nice GeoPDF export built in. But if you want to automate things, I understand that the automated solution might be better for your workflow. 

*Disclaimer: QGIS 3.10 must be compiled with GDAL >= 3.0 and proj6, which as far as I know is currently not the case for QGIS Windows standalone builds. See also https://gis.stackexchange.com/questions/340030/create-geospatial-pdf-geopdf-is-greyed-out-in-pdf-export-options-in-qgis-3-10 

Greetings, 

Andreas 


On 2019-11-11 08:28, paul.m...@lfv.se wrote:


Hi list, 

I have a question on how to export a PDF file from PostGIS with a color on the lines instead of the default black lines. I have searched on the internet but have not reached all the way... 

I have 2 tables that I would like to export into test.pdf (rivers and roads) 

ogr2ogr -f "PDF" c:\Temp\test.pdf PG:"host=xxx.xxx.xxx.x user= dbname=testdb password=pwd" rivers roads 

I would, for instance set like to set line width to 1 px and color to 4040FF on rivers, 

Width 3 px and color FF4040 on roads. 

Thanks, 

Paul 


___
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] ogr2ogr PDF

[Andreas Neumann]

Hi Paul, 


ogr2ogr usually doesn't care much about styling, unless you use ogr
feature styles: 

https://svn.osgeo.org/gdal/trunk/gdal/ogr/ogr_feature_style.html 


Or you use QGIS 3.10* which has a nice GeoPDF export built in. But if
you want to automate things, I understand that the automated solution
might be better for your workflow. 


*Disclaimer: QGIS 3.10 must be compiled with GDAL >= 3.0 and proj6,
which as far as I know is currently not the case for QGIS Windows
standalone builds. See also
https://gis.stackexchange.com/questions/340030/create-geospatial-pdf-geopdf-is-greyed-out-in-pdf-export-options-in-qgis-3-10


Greetings, 

Andreas 


On 2019-11-11 08:28, paul.m...@lfv.se wrote:





Hi list, 

I have a question on how to export a PDF file from PostGIS with a color on the lines instead of the default black lines. I have searched on the internet but have not reached all the way… 

I have 2 tables that I would like to export into test.pdf (rivers and roads) 

ogr2ogr -f "PDF" c:\Temp\test.pdf PG:"host=xxx.xxx.xxx.x user= dbname=testdb password=pwd" rivers roads 

I would, for instance set like to set line width to 1 px and color to 4040FF on rivers, 

Width 3 px and color FF4040 on roads. 

Thanks, 

Paul 
___

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] On external PDF libraries

[Andreas Neumann]

Hi Even,

Yes, the make clean and recompile did the trick. Now the output of 
ogr/gdalinfo seems correct and QGIS can export to GeoPDF.


Many thanks for your help!

Andreas

Am 21.08.19 um 14:49 schrieb Even Rouault:

On mercredi 21 août 2019 14:38:39 CEST Andreas Neumann wrote:

Hi Even,

I think I got building with poppler to work.

gdalinfo and ogrinfo show both:

PDF -raster,vector- (w+): Geospatial PDF

It should display '(rw+vs)' with r for 'read'
If you've made several buid attempts while playing with ./configure, make sure
to 'make clean' before rebuilding.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] On external PDF libraries

[Andreas Neumann]

Hi Even,

I think I got building with poppler to work.

gdalinfo and ogrinfo show both:

PDF -raster,vector- (w+): Geospatial PDF

However, QGIS still thinks there is no PDF read support in QGIS. When 
trying to export to GeoPDF there is a message:


GDAL PDF driver was not build with PDF read support. A build with PDF 
read support is required for GeoPDF creation.


Any ideas what might still be wrong?

Why is QGIS complaining about PDF read support when I want to export GeoPDF?

Thanks and greetings,

Andreas

Am 21.08.19 um 13:12 schrieb Even Rouault:

Andreas,


I am trying to test GeoPDF support in QGIS and have questions on the
external library dependencies in GDAL. I am trying to interpret the
notes on https://gdal.org/drivers/raster/pdf.html

Which of the three options (Poppler, PoDoFo, PDFium) is recommended? I
work on Ubuntu 18.04 and I can build libraries from source if necessary.
PoDoFo seems limited - so better not use it?

For non-rendering tasks such as creating a PDF, it should be OK, but I know I
had issues at runtime with recent versions of PoDoFo


PDFium seems to be
complicated to install -

Yes, and the driver assumes an old version of PDFium. Would require some work
to make it work with newer ones.


so perhaps poppler?

That's probably the simplest option and it will give you good results. No need
to build it from source. The version already compiled in your distro is fine.
Install the 'libpoppler-private-dev' package before building GDAL with
./configure --with-poppler

Even


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] On external PDF libraries

[Andreas Neumann]

Hi, 


I am trying to test GeoPDF support in QGIS and have questions on the
external library dependencies in GDAL. I am trying to interpret the
notes on https://gdal.org/drivers/raster/pdf.html 


Which of the three options (Poppler, PoDoFo, PDFium) is recommended? I
work on Ubuntu 18.04 and I can build libraries from source if necessary.
PoDoFo seems limited - so better not use it? PDFium seems to be
complicated to install - so perhaps poppler? Or should I try PDFium? 

Thanks for any recommendations, 


Andreas___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Alternative to GPKG format

[Andreas Neumann]

Hi,

Just a quick stupid question: are you writing to a local file system or 
to a network filesystem. The latter can be substantially slower than the 
former, esp. with Geopackage.


Andreas

Am 01.11.18 um 12:10 schrieb koji higuchi:

Hi Even
I managed to write gpkg without ogr without fiona using class 
ShapeConverter(osmium.SimpleHandler).

still, speed seems slow.
Any idea to increase it up.

On Thu, Nov 1, 2018 at 7:05 PM koji higuchi > wrote:


Hi Even

I am trying to replace using fiona by pure ogr.
but having difficult to collapse the code with class and objects.
If i could extract geom and tags in a ogr pythonic way, then it be
better


On Thu, Nov 1, 2018 at 6:45 PM Even Rouault
mailto:even.roua...@spatialys.com>>
wrote:

You are perhaps using a too old version of Fiona. Recent
versions insert
features within OGR transactions. Should be fine with latest
Fiona 1.8.0
See https://github.com/Toblerity/Fiona/issues/476

> Hi, following is the code I used:
>
> Import os, osmium, fiona
>
> fi = 'europe-latest.osm.pbf'
> fo = 'europe-latest.dpkg'
>
> drv = 'DPKG'
>
> crs = {'no_defs': True, 'ellps': 'WGS84', 'datum': 'WGS84',
'proj':
> 'longlat'}
>
>  schema = {'geometry': 'LineString',
>                    'properties': {'id': 'float', 'name' :
'str', 'kind' :
> 'str'}}
>
> outfile = fiona.open(fo, 'w', driver=drv, crs=crs,
schema=schema)
>
> geomfab = osmium.geom.GeoJSONFactory()
>
> class ShapeConverter(osmium.SimpleHandler):
>       def way(self, w):
>            if 'place' in w.tags:
>                rec = {'geometry' :
eval(geomfab.create_linestring(w)),
>                       'properties' : {'id' : float(w.id
),
>                                      'name' :
w.tags.get('name'),
>                                        'kind' :
w.tags['place']}}
>                outfile.write(rec)
>
> ShapeConverter().apply_file(fi, locations=True)
>
> On Thu, Nov 1, 2018 at 4:10 PM jratike80 <
>
> jukka.rahko...@maanmittauslaitos.fi
> wrote:
> > koji higuchi wrote
> >
> > > Hi
> > > I am extracting .osm.pbf file into .gpkg; but the
writing rate is very
> > > slow.
> > > When I write into .shp, rate is faster but its limit is 4gb.
> > > So, what other format is better for larger than 4gb
requirement?
> > > Thanks for your ideas.
> > > Koji
> >
> > Hi,
> >
> > Show the exact command that you are using so we can see if
it could be
> > made
> > faster. For example if you happen to use -skipfailures for
handling the
> > invalid geometries of the OSM data then you will make GDAL
to do a new
> > transaction for each row and that certainly is slow. But
let's have a look
> > at your command first.
> >
> > -Jukka Rahkonen-
> >
> >
> >
> > --
> > Sent from:
http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org 
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
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] Twenty years of GDAL !

[Andreas Neumann]

Hi gdal-devs,

Many thanks for your efforts in the past years - it is much appreciated!

Many people don't realize that they use your software (behind the 
scenes) on every work day ...


It is nice to be able to use your drivers and utilities and build 
something on top of it - without restrictions!


Greetings,

Andreas


Am 18.10.2018 um 09:23 schrieb Mateusz Loskot:

Happy Birthday GDAL!


GDAL is an important project for me personally.
Back in 2006, a completely accidental chat with Frank Warmerdam on IRC
led me to change my job - in January 2007 I became GDAL paid maintainer -
and sequence of events that followed led to a significant change of my
professional career.

Thanks Frank and all the members of the GDAL Team and Community!

Best regards,
Mateusz

On Thu, 18 Oct 2018 at 03:51, Even Rouault  wrote:

Hi,

I nearly missed it [1] (actually I'm already on the 18th here, but let's 
consider
Canadian time so still on the 17th), but exactly 20 years go on Oct 17th 1998,
Frank Warmerdam committed for the first time in the CSV repository.

'''
commit 149db916aafcbee9bb64572fafda83441c94a552
Author: Frank Warmerdam 
Date:   Sat Oct 17 19:24:36 1998 +

 Initial implementation.


 git-svn-id: https://svn.osgeo.org/gdal/trunk@2 
f0d54148-0727-0410-94bb-9a71ac55c965
'''

https://github.com/OSGeo/gdal/commit/149db916aafcbee9bb64572fafda83441c94a552

169 lines for a first version of the virtual I/O layer...

Since then,
* 39075 commits have been added on top of it,
* 159 raster drivers
* 96 vector drivers [2]
* by 161 committers (actually there are more contributors, here just counting
   the ones who have directly authored a CVS, SVN or git commit),
* adding 7110 files in the repository, for a grand total of
* 2.192 millions lines in 3745 files with extensions c, cpp, h, hh, hpp, py,
   html, java, cs, i, pl, vc, sh, bat, dox, ac, GNUmakefile (80 MB) (all the 
text files)
   so an average of 300 lines per day added
* 64 releases
* 6287 tickets closed
* 49097 messages posted on gdal-dev
* more than 100 software proudly mentionning using it

Happy birthday and long life to GDAL and its commmnity of contributors, either
by code, documentation, testing, packaging, reports, ... !

Even

[1] thanks to Robert Coup for reminding me a few days ago about the approaching 
date !
[2] you'll note that 155 + 96 = 255, but I don't think there's a
 Byte limitation for the number of drivers ...

--
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] ogr2ogr and nlt question

[Andreas Neumann]

answering myself: apparently ogr2ogr accepts two -nlt parameters and the
result looks ok (correct type and correctly segmentized from the
original CURVEPOLYGON). 

So all good in this respect. 

Andreas 

On 2017-09-29 08:32, Andreas Neumann wrote:

> Hi, 
> 
> when using ogr2ogr I can fix the geometry type for cases where I use SQL 
> statements. 
> 
> Can I use nlt multiple times? In my case I would like to specify -nlt 
> CONVERT_TO_LINEAR to convert from CompounCurve to Polygon and then use -nlt 
> POLYGON to tell it you are really a POLYGON. Is this possible to use the -nlt 
> parameter twice? 
> 
> Thank you for your reply, 
> 
> Andreas 
> ___
> 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] ogr2ogr and nlt question

[Andreas Neumann]

sorry - I meant to say that I convert CURVEPOLYGON to POLYGON, not
COMPOUNDCURVE TO POLYGON. 

Andreas 

On 2017-09-29 08:32, Andreas Neumann wrote:

> Hi, 
> 
> when using ogr2ogr I can fix the geometry type for cases where I use SQL 
> statements. 
> 
> Can I use nlt multiple times? In my case I would like to specify -nlt 
> CONVERT_TO_LINEAR to convert from CompounCurve to Polygon and then use -nlt 
> POLYGON to tell it you are really a POLYGON. Is this possible to use the -nlt 
> parameter twice? 
> 
> Thank you for your reply, 
> 
> Andreas 
> ___
> 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

[gdal-dev] ogr2ogr and nlt question

[Andreas Neumann]

Hi, 

when using ogr2ogr I can fix the geometry type for cases where I use SQL
statements. 

Can I use nlt multiple times? In my case I would like to specify -nlt
CONVERT_TO_LINEAR to convert from CompounCurve to Polygon and then use
-nlt POLYGON to tell it you are really a POLYGON. Is this possible to
use the -nlt parameter twice? 

Thank you for your reply, 

Andreas___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Opening gridded xyz data that is out of order

[Andreas Neumann]

Hi Joaquim,

Interesting. Thanks for sharing. As always with OpenSource there are 
more solutions than just one ;-)


Yes, I am aware about the missing data in the lower right corner - this 
is outside of the province and outside of my area of interest.


Thanks and greetings,

Andreas


On 11.09.2017 16:45, Joaquim Luis wrote:

You could have done it with GMT as well

gmtinfo DTM_swissALTI3D_XYZ.txt -I2
-R2708001/2717999/1210001/121

xyz2grd -R2708001/2717999/1210001/121 -I2 
-GDTM_swissALTI3D_XYZ.grd DTM_swissALTI3D_XYZ.txt


and you get a netCDF grid (it can do GeoTIFs too but would need to go 
see the docs)


The grid misses a tile of data at the lower right corner

Joaquim

Hi Mark (and others),

Your sort command worked like a charm. It was also very fast!

Now gdalinfo produces this nice information output:

Driver: XYZ/ASCII Gridded XYZ
Files: dtmav_sorted.xyz
Size is 5000, 5000
Coordinate System is `'
Origin = (2708000.000,121.000)
Pixel Size = (2.000,2.000)
Corner Coordinates:
Upper Left  ( 2708000.000, 121.000)
Lower Left  ( 2708000.000, 122.000)
Upper Right ( 2718000.000, 121.000)
Lower Right ( 2718000.000, 122.000)
Center  ( 2713000.000, 1215000.000)
Band 1 Block=5000x1 Type=Float32, ColorInterp=Undefined
  Min=728.210 Max=2294.290
  NoData Value=0

Now I can open this in QGIS as a normal data source and simply
safe as a GeoTIFF file.

Thanks a lot to all who answered so quickly!

Glad that a simple sort command on the command line helped to
solve the issue! I will contact the data provider and ask them if
they could deliver this data in an already sorted form so that
GDAL recognizes it as gridded data.

Andreas


On 11.09.2017 16:12, Mark Johnson wrote:

You must sort the data beforehand
- the y position must be sorted properly (ASC or DESC)

Standard linux sort program:

sort -k2 -n -k1 392_5810.xyz  -o
392_5810.sort.xyz 

(2nd column (y) as numeric, then first column (x) -o = output file

As a zip file you can also do:

unzip -p 390_5820.zip | sort -k2 -n -k1 -o ../xyz/390_5820.dhhn92.txt

that would deal with problem in 1 step.

ogr needs to know the range/area to build (minx,miny,maxx, maxy),
so when the y switches it assumes a new column.

Mark


___
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] Opening gridded xyz data that is out of order

[Andreas Neumann]

Yes - I am aware of gdal_translate and gdalwarp to translate formats.

Thanks a lot. I am very happy that this was so easy to solve and now I 
can use this data in QGIS.


I think the data provider just concatenated chunks of existing files and 
did not care about the order. I will ask them to run the magic sort 
command you provided before delivering the data to their clients.


Thanks,
Andreas

On 11.09.2017 16:44, Mark Johnson wrote:

This will do the same, just replace the EPSG code number:

gdal_translate -ot Float32 -a_srs EPSG:25833 
../xyz/390_5820.dhhn92.txt ../2007.390_5820.dhhn92.25833.tif


Mark


___
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] Opening gridded xyz data that is out of order

[Andreas Neumann]

Hi Mark (and others),

Your sort command worked like a charm. It was also very fast!

Now gdalinfo produces this nice information output:

Driver: XYZ/ASCII Gridded XYZ
Files: dtmav_sorted.xyz
Size is 5000, 5000
Coordinate System is `'
Origin = (2708000.000,121.000)
Pixel Size = (2.000,2.000)
Corner Coordinates:
Upper Left  ( 2708000.000, 121.000)
Lower Left  ( 2708000.000, 122.000)
Upper Right ( 2718000.000, 121.000)
Lower Right ( 2718000.000, 122.000)
Center  ( 2713000.000, 1215000.000)
Band 1 Block=5000x1 Type=Float32, ColorInterp=Undefined
  Min=728.210 Max=2294.290
  NoData Value=0

Now I can open this in QGIS as a normal data source and simply safe as a 
GeoTIFF file.


Thanks a lot to all who answered so quickly!

Glad that a simple sort command on the command line helped to solve the 
issue! I will contact the data provider and ask them if they could 
deliver this data in an already sorted form so that GDAL recognizes it 
as gridded data.


Andreas


On 11.09.2017 16:12, Mark Johnson wrote:

You must sort the data beforehand
- the y position must be sorted properly (ASC or DESC)

Standard linux sort program:

sort -k2 -n -k1 392_5810.xyz  -o 
392_5810.sort.xyz 


(2nd column (y) as numeric, then first column (x) -o = output file

As a zip file you can also do:

unzip -p 390_5820.zip | sort -k2 -n -k1 -o ../xyz/390_5820.dhhn92.txt

that would deal with problem in 1 step.

ogr needs to know the range/area to build (minx,miny,maxx, maxy), so 
when the y switches it assumes a new column.


Mark


___
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] Opening gridded xyz data that is out of order

[Andreas Neumann]

Hi,

Forgot to mention the link to the file, just in case you have time 
testing - see https://services.geo.zg.ch/temp/dtmav.zip (138 MB zipped 
file).


Thanks,

Andreas


On 11.09.2017 15:43, Andreas Neumann wrote:

Hi,

I received a DTM from a Swiss province (OpenData) which is of the 
following format:


One coordinate per line, already gridded. See f.e.

2708001.00 1218001.00 1541.52
2708003.00 1218001.00 1542.35
2708005.00 1218001.00 1542.98
2708007.00 1218001.00 1543.58
2708009.00 1218001.00 1544.20
2708011.00 1218001.00 1545.13
2708013.00 1218001.00 1545.88

The issue is that further down the file there seems to be an issue of 
ordering the coordinates. gdalinfo produces the following error:


ERROR 1: Ungridded dataset: At line 4125001, change of Y direction
gdalinfo failed - unable to open 'DTM_swissALTI3D_XYZ.txt'.

If GDAL could open the data - it would open as ungridded data - right? 
Issue is, this data is already gridded as you can see above. I 
actually want to save this is a gridded GeoTIFF file for later usage 
in QGIS.


Is there still a chance that GDAL can open this data set, even if 
coordinates are out of order?


How about the gridded vs ungridded aspect of xyz files?

Thanks,

Andreas



___
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

[gdal-dev] Opening gridded xyz data that is out of order

[Andreas Neumann]

Hi,

I received a DTM from a Swiss province (OpenData) which is of the 
following format:


One coordinate per line, already gridded. See f.e.

2708001.00 1218001.00 1541.52
2708003.00 1218001.00 1542.35
2708005.00 1218001.00 1542.98
2708007.00 1218001.00 1543.58
2708009.00 1218001.00 1544.20
2708011.00 1218001.00 1545.13
2708013.00 1218001.00 1545.88

The issue is that further down the file there seems to be an issue of 
ordering the coordinates. gdalinfo produces the following error:


ERROR 1: Ungridded dataset: At line 4125001, change of Y direction
gdalinfo failed - unable to open 'DTM_swissALTI3D_XYZ.txt'.

If GDAL could open the data - it would open as ungridded data - right? 
Issue is, this data is already gridded as you can see above. I actually 
want to save this is a gridded GeoTIFF file for later usage in QGIS.


Is there still a chance that GDAL can open this data set, even if 
coordinates are out of order?


How about the gridded vs ungridded aspect of xyz files?

Thanks,

Andreas



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr - exclude table option?

[Andreas Neumann]

Thanks Even!

The VACUUM command worked and indeed the file is now much smaller.

Thank you for adding this information to the Geopackage documentation!

I wasn't aware that I could run any SQL command through ogrinfo. Nice!

Greetings,

Andreas


Am 30.11.2016 um 21:24 schrieb Even Rouault:


On mercredi 30 novembre 2016 21:11:14 CET Andreas Neumann wrote:

> Hi Even,

>

> Thanks. I will use the 'ogrinfo your.gpkg -sql "DROP TABLE table_name"'

> trick for now.

>

> One thing though: I noticed that the filesize doesn't really shrink. Is

> there a way to compact/vacuum the geopackage after removal of the table?

You actually mentionned the appropriate SQL command: VACUUM :-)

I've just added this new paragraph to http://gdal.org/drv_geopackage.html:

"""When dropping a table, or removing records from tables, the space they

occupied is not immediately released and kept in the pool of file 
pages that


SQLite may reuse later. If you need to shrink the file to its minimum 
size,


you need to issue an explicit "VACUUM" SQL request. Note that this will

result in a full rewrite of the file."""

Even

--

Spatialys - Geospatial professional services

http://www.spatialys.com



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr - exclude table option?

[Andreas Neumann]

Hi Even,

Thanks. I will use the 'ogrinfo your.gpkg -sql "DROP TABLE table_name"' 
trick for now.


One thing though: I noticed that the filesize doesn't really shrink. Is 
there a way to compact/vacuum the geopackage after removal of the table?


The table I remove is rather big - so it would have quite an effect on 
the filesize.


--

On the blacklist / exclude table options for table transfer from Postgis 
to GPKG - can you please send me an estimate/quote offlist? Depending on 
how much this costs, I would be interested in paying for that.


Thanks a lot,

Andreas

Am 30.11.2016 um 18:05 schrieb Even Rouault:


On mercredi 30 novembre 2016 16:21:42 CET Neumann, Andreas wrote:

> Hi,

>

> I want to convert a whole Postgis schema to a geopackage. This works

> fine with

>

> ogr2ogr -f GPKG av_1700.gpkg PG:'dbname=dbname host=localhost

> schemas=schemaname'

>

> Now - my problem is that the schema contains 64 tables and I want to

> convert all tables except one table.

>

> Is there a trick with an exclude option? I know that I can list all

> tables that I want to convert in the sense of a white list with

> 'tables=tab1,tab2,tab3', etc. - but this is complicated for this many

> tables.

>

> I hope that there is / could be some black list option - or the

> possibility of specifying a pattern for selection the tables to be

> converted.

Andreas,

There's no such option (there's no real technical hurdle if one would 
want to add one, but one can wonder how common this use case is)


The easiest way currently would be to drop the unwished tables after 
the import : ogrinfo your.gpkg -sql "DROP TABLE table_name". Since 
GDAL 2.1.2, this not only drops the table but also all references to 
it in GPKG system tables.


You could also do a tiny script to list the tables and remove the 
one(s) you don't want from the list before calling ogr2ogr / 
gdal.VectorTranslate()


Even

--

Spatialys - Geospatial professional services

http://www.spatialys.com



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Question on WFS and encoding

[Andreas Neumann]

Thanks for the temporary workaround - but it is for the server admin to 
fix the issue.


Andreas

On 18.06.2015 16:27, Jukka Rahkonen wrote:

Even Rouault  spatialys.com> writes:

  

No easy workaround on OGR side since the OGR GML driver will honour the

XML encoding indication to do recoding (from what it assumes to be
ISO-8859-1, but is UTF-8) to UTF-8...

Hi,

If you just need the data a non-OGR workaround is to save the GML on disk
and correct the encoding string by hand or with sed or something.

-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

[gdal-dev] Question on WFS and encoding

[Andreas Neumann]

Hi,

I want to transform a WFS to Postgis, using this WFS service:

http://wms.zh.ch/NEKWMS with the layer "landwirtschaftliche-nutzungseignung"

While this works fine, there seems to be an issue with encoding. German 
Umlauts are not correctly displayed after the transformation. Is there a 
way to specify the encoding in ogr2ogr or with some options for WFS?


http://www.gdal.org/drv_wfs.html does not list an encoding option.

Or is it a misconfiguration of the server, if the Umlauts do not display 
correctly?


Thank you for any hints!

Andreas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_calc.py and NoData issues

[Andreas Neumann]

Hi Simen,

<> means not - same as !=

Andreas

Am 2014-11-19 15:09, schrieb Simen Langseth:

I saw the symbol <> first time in gdal calc what is meaning of it?

Thanks

On Wed, Nov 19, 2014 at 10:21 PM, Even Rouault
 wrote:


Le mercredi 19 novembre 2014 14:16:05, Andreas Neumann a écrit :

Hi Even,

Thank you for trying to help. Unfortunately, the --overwrite

option does

not help.

I have a very small test file at

http://webgis.uster.ch/temp/test.tif [1]


I used the following options:

gdal_calc.py -A test.tif --overwrite --outfile=testcalc.tif
--calc="(A==249)*255+(A<>249)*A"

All pixels with values of "255" are now "nodata" after running

gdal_calc

;-(


I wrote "as well", so try with "--overwrite --nodata 99".



May I please ask you to test/verify this?

Thanks a lot!

Andreas

Am 2014-11-19 13:58, schrieb Even Rouault:



Le mercredi 19 novembre 2014 13:49:48, Andreas Neumann a écrit

:

>> Hi,
>>
>> I have an issue with gdal_calc.py and nodata values.
>>
>> My input data contains a lot of white pixels. After running
>> gdal_calc.py
>> with the following parameters
>>
>> gdal_calc.py -A test.tif --outfile=testcalc.tif
>> --calc="(A==249)*255+(A<>249)*A"
>>
>> it turns out that all pixel values with 255 are now nodata

values ;-(

>> Is
>> there an option so that my 255 values are not turned into

nodata? I

>> tested with the --NoDataValue option (e.g. 99 - which I don't

use in

>> the
>> image), but it seems to be ignored. For me it is important

that black

>> and white pixels are preserved.
>
> Use --overwrite as well, since otherwise the existing output

file will

> be used
> to be just updated and not recreated.
> It would be appropriate that the utility warns that

--NoDataValue has

> no effect
> when the output file exists.
>
>> Thanks for any hints,
>> Andreas
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev [2]


--
Spatialys - Geospatial professional services
http://www.spatialys.com [3]
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev [2]




Links:
--
[1] http://webgis.uster.ch/temp/test.tif
[2] http://lists.osgeo.org/mailman/listinfo/gdal-dev
[3] http://www.spatialys.com

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_calc.py and NoData issues

[Andreas Neumann]

oh - sorry. This helps.

Correct syntax is:
gdal_calc.py -A test.tif --overwrite --NoDataValue=99 
--outfile=testcalc.tif --calc="(A==249)*255+(A<>249)*A"


Thanks a lot!

Andreas

Am 2014-11-19 14:21, schrieb Even Rouault:

Le mercredi 19 novembre 2014 14:16:05, Andreas Neumann a écrit :

Hi Even,

Thank you for trying to help. Unfortunately, the --overwrite option 
does

not help.

I have a very small test file at http://webgis.uster.ch/temp/test.tif

I used the following options:

gdal_calc.py -A test.tif --overwrite --outfile=testcalc.tif
--calc="(A==249)*255+(A<>249)*A"

All pixels with values of "255" are now "nodata" after running 
gdal_calc

;-(


I wrote "as well", so try with "--overwrite --nodata 99".



May I please ask you to test/verify this?

Thanks a lot!

Andreas

Am 2014-11-19 13:58, schrieb Even Rouault:
> Le mercredi 19 novembre 2014 13:49:48, Andreas Neumann a écrit :
>> Hi,
>>
>> I have an issue with gdal_calc.py and nodata values.
>>
>> My input data contains a lot of white pixels. After running
>> gdal_calc.py
>> with the following parameters
>>
>> gdal_calc.py -A test.tif --outfile=testcalc.tif
>> --calc="(A==249)*255+(A<>249)*A"
>>
>> it turns out that all pixel values with 255 are now nodata values ;-(
>> Is
>> there an option so that my 255 values are not turned into nodata? I
>> tested with the --NoDataValue option (e.g. 99 - which I don't use in
>> the
>> image), but it seems to be ignored. For me it is important that black
>> and white pixels are preserved.
>
> Use --overwrite as well, since otherwise the existing output file will
> be used
> to be just updated and not recreated.
> It would be appropriate that the utility warns that --NoDataValue has
> no effect
> when the output file exists.
>
>> Thanks for any hints,
>> Andreas
>> ___
>> 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] Fwd: Re: gdal_calc.py and NoData issues

[Andreas Neumann]

forgot to send this to the list. Sorry.

see below:

 Originalnachricht 
Betreff: Re: [gdal-dev] gdal_calc.py and NoData issues
Datum: 2014-11-19 14:16
Von: Andreas Neumann 
An: Even Rouault 

Hi Even,

Thank you for trying to help. Unfortunately, the --overwrite option does 
not help.


I have a very small test file at http://webgis.uster.ch/temp/test.tif

I used the following options:

gdal_calc.py -A test.tif --overwrite --outfile=testcalc.tif 
--calc="(A==249)*255+(A<>249)*A"


All pixels with values of "255" are now "nodata" after running gdal_calc 
;-(


May I please ask you to test/verify this?

Thanks a lot!

Andreas

Am 2014-11-19 13:58, schrieb Even Rouault:

Le mercredi 19 novembre 2014 13:49:48, Andreas Neumann a écrit :

Hi,

I have an issue with gdal_calc.py and nodata values.

My input data contains a lot of white pixels. After running 
gdal_calc.py

with the following parameters

gdal_calc.py -A test.tif --outfile=testcalc.tif
--calc="(A==249)*255+(A<>249)*A"

it turns out that all pixel values with 255 are now nodata values ;-( 
Is

there an option so that my 255 values are not turned into nodata? I
tested with the --NoDataValue option (e.g. 99 - which I don't use in 
the

image), but it seems to be ignored. For me it is important that black
and white pixels are preserved.


Use --overwrite as well, since otherwise the existing output file will 
be used

to be just updated and not recreated.
It would be appropriate that the utility warns that --NoDataValue has 
no effect

when the output file exists.



Thanks for any hints,
Andreas
___
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_calc.py and NoData issues

[Andreas Neumann]

Hi,

I have an issue with gdal_calc.py and nodata values.

My input data contains a lot of white pixels. After running gdal_calc.py 
with the following parameters


gdal_calc.py -A test.tif --outfile=testcalc.tif 
--calc="(A==249)*255+(A<>249)*A"


it turns out that all pixel values with 255 are now nodata values ;-( Is 
there an option so that my 255 values are not turned into nodata? I 
tested with the --NoDataValue option (e.g. 99 - which I don't use in the 
image), but it seems to be ignored. For me it is important that black 
and white pixels are preserved.


Thanks for any hints,
Andreas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdalnumeric issue

[Andreas Neumann]

Hi,

I wanted to run gdal_calc.py

When I run it, it complains about an import error:

-
Traceback (most recent call last):
  File "/usr/local/bin/gdal_calc.py", line 50, in 
from gdalnumeric import *
ImportError: No module named gdalnumeric
-

However, it seems to present on my system at the path 
/usr/local/lib/python2.7/dist-packages/osgeo/gdalnumeric.py


How can I tell gdal_calc.py where to find gdalnumeric?

Thank you for any hints!

Andreas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Problem with nearblack

[Andreas Neumann]

Hi,

I have a grayscale tiff file and would like to remap a grayscale value 
of 249 to white (255).


I used the following command:

nearblack -white -color 249 -near 0 -of GTIFF -o temp_white.tif temp.tif

and also tried

nearblack -white -color 249 -near 1 -of GTIFF -o temp_white.tif temp.tif

But nothing changed. 249 stays as 249. Is there another way to remap my 
specific grayscale value 249 to white with gdal?


Thank you for any hints,
Andreas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Call for discussion for "RFC 41 : Support for multiple geometry fields in OGR"

[Andreas Neumann]

Hi,

I can't comment about the technical issues. But from a user point of
view there is a need to have more than one geometry representation per
feature. There could be several generalizations attached to a feature,
or different states.

I would welcome such a feature in OGR.

I guess Swisstopo also has a specific use case in mind since they
sponsor the work. Do you know which?

Andreas

Am 24.07.2013 15:52, schrieb Howard Butler:
> 
> On Jul 24, 2013, at 8:47 AM, Even Rouault  
> wrote:
>> Too verbose maybe ;-) , since you probably missed the (discrete) mention to 
>> the OLCCreateGeomField capability (at layer level since CreateGeomField() is 
>> a 
>> OGRLayer method)
> 
> Indeed. Thanks for a thorough RFC. Now people can move on to arguing whether 
> or not multiple geometry fields in a data source is a good idea :)
> 
> Howard
> ___
> 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] Multiple pens in OGR feature style

[Andreas Neumann]

Hi Marco and others,

If the (DXF) writer does not support multiple strokes - can you perhaps
export the same feature multiple times using the corresponding OGR
features styles? Ideally, this would honour the symbol levels, if
defined, in QGIS to get the same symbology.

Do you think this is possible?

Thanks,
Andreas



Am 10.12.2012 17:19, schrieb Marco Hugentobler:
> Hi Even
> 
> 
> 
> Ok, so it seems to depend on the format properties.
> 
> Hi Even
> 
> You are right, it seems to depend on the output driver/format. Actually
> my main interest is the dxf format, it seems that one takes the first
> element of the style. Don't know if there are drivers which handle
> multiple pens / brushes. So probably I'll write everything into the
> style string and let the driver do what's best for the concrete format.
> 
> Thanks,
> Marco
> 
> On 10.12.2012 15:29, Even Rouault wrote:
>> Selon Marco Hugentobler :
>>
>>> Hi
>>>
>>> I'm currently implementing support for OGR feature styles in the QGIS
>>> vector layer export. In QGIS symbology, there is the possibility to
>>> compose a symbol with multiple symbol layers, e.g. a broad black line
>>> with a thin white line on top of it for a road symbol. Is this supported
>>> by the OGR feature styles to have multiple pens / brushes in the same
>>> symbol string?
>>> I tried the style string
>>> 'PEN(c:#008000,w:3mm,l:1);PEN(c:#ff,w:2mm,l:2)'. However, in a kml
>>> export, only the first style seems to be picked up. So I wonder if there
>>> is something wrong with my style string or if it is not supported by the
>>> feature style mechanism.
>> Marco,
>>
>> I was surprised that multiple pens were allowed, but yes, there
>> doesn't seem to
>> be any limitation on multiple instanciations of the same style tool in
>> the spec
>> or the generic code of the OGR FeatureStyle implementation. However
>> I'd be
>> surprised that many drivers (and formats) can handle that properly.
>>
>> Looking at addstylestring2kml() in
>> ogr/ogrsf_frmts/libkml/ogrlibkmlstyle.cpp, I
>> can see that only one PEN instance will be taken into account (looking
>> at the
>> coulde, I would have said that it would be the last occurence...). And
>> it seems
>> that it is a limitation of LIBKML itself, since the Style class seems
>> to accept
>> only one line style.
>>
>> http://code.google.com/searchframe#y2CS_eJ3ink/trunk/src/kml/dom/style.h&q=style.h%20package:libkml\.googlecode\.com
>>
>>
>> Best regards,
>>
>> Even
> 
> 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem installing gdal from source - dxf-related?

[Andreas Neumann]

Hi Even and others,

I did a new checkout and installation works fine now.

I also tested the recent dxf writer improvements and can gladly report 
that filled polygon export now seems to work fine. It also works for 
holes. Multipolygon features seem to exported as separate polygons. But 
that is fine for me and perhaps also a limitation of dxf.


Thank you for all who worked on fixing the dxf export issues!

Andreas

On Mon, 01 Oct 2012 16:33:31 +0200, Even Rouault wrote:

Andreas,

I suspect that your source files don't match the "official" ones. The 
line

numbers don't point to the line numbers of the SVN version. There
must have been
an error in the process when you updated your source files.

Even


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Problem installing gdal from source - dxf-related?

[Andreas Neumann]

Hi,

I tried to test the latest DXF fixes - but get an error message during 
installation. The compile works fine, but during install I get the 
following message:




make[3]: Entering directory `/home/an/dev/gdal/ogr/ogrsf_frmts/dxf'
/bin/bash /home/an/dev/gdal/libtool --mode=compile --tag=CXX g++ -g -O2 
-Wall  -I.. -I../.. -I/home/an/dev/gdal/port -I/home/an/dev/gdal/gcore 
-I/home/an/dev/gdal/alg -I/home/an/dev/gdal/ogr 
-I/home/an/dev/gdal/ogr/ogrsf_frmts -DOGR_ENABLED 
-I/home/an/dev/gdal/port  -c -o ../o/ogrdxfwriterlayer.lo 
ogrdxfwriterlayer.cpp
libtool: compile:  g++ -g -O2 -Wall -I.. -I../.. 
-I/home/an/dev/gdal/port -I/home/an/dev/gdal/gcore 
-I/home/an/dev/gdal/alg -I/home/an/dev/gdal/ogr 
-I/home/an/dev/gdal/ogr/ogrsf_frmts -DOGR_ENABLED 
-I/home/an/dev/gdal/port -c ogrdxfwriterlayer.cpp  -fPIC -DPIC -o 
../o/.libs/ogrdxfwriterlayer.o
ogrdxfwriterlayer.cpp: In member function 'OGRErr 
OGRDXFWriterLayer::WritePOINT(OGRFeature*)':
ogrdxfwriterlayer.cpp:384:1: error: a function-definition is not 
allowed here before '{' token
ogrdxfwriterlayer.cpp:332:19: warning: unused variable 'poTool' 
[-Wunused-variable]

ogrdxfwriterlayer.cpp:1178:1: error: expected '}' at end of input
ogrdxfwriterlayer.cpp:1178:1: warning: control reaches end of non-void 
function [-Wreturn-type]

make[3]: *** [../o/ogrdxfwriterlayer.lo] Error 1
make[3]: Leaving directory `/home/an/dev/gdal/ogr/ogrsf_frmts/dxf'
make[2]: *** [dxf-target] Error 2
make[2]: Leaving directory `/home/an/dev/gdal/ogr/ogrsf_frmts'
make[1]: *** [sublibs] Error 2
make[1]: Leaving directory `/home/an/dev/gdal/ogr'
make: *** [ogr-target] Error 2



Tonight I will test on a different machine to see if the problem is 
reproducible.


Thank you if you have any idea how I can fix the problem,
Andreas

--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[Andreas Neumann]

Hi,

I agree that such a provider would probably slow - too slow for a 
server, unless the data is cached somewhere (e.g. sqlite) and ogr only 
reads new/updated files, and the rest from the cache.


On the other hand it would still be useful for conversion into other 
formats, where speed perhaps doesn't matter that much.


Andreas

On Mon, 23 Jul 2012 11:26:31 -0400, Daniel Morissette 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 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



--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
_

Re: [gdal-dev] Oracle support available by default in any OSGeo software

[Andreas Neumann]

ble. Ok
 It's a good
 >  >  reason.

 You can freely download all the necessary files to compile against 
OCI

 from [LINK: http://oracle.com] oracle.com.

 >  >
 >  >  I found a library, called OCILIB (<[LINK:
 >  >  [LINK: http://orclib.sourceforge.net/]
 http://orclib.sourceforge.net/] [LINK: 
http://orclib.sourceforge.net/]

 http://orclib.sourceforge.net/>), that

 >  >  enable your software to dynamically connect to your oracle
 database. This
 >  >  library does not require any oracle library to compile. It's
 available on
 >  >  any platform where oracle client is available and it licensed 
with

 LGPL.

 The OCILIB library is just a shell around OCI. You still need OCI
 distribution from a server, client or instant client installation 
in order

 to compile or run any code based on that library.


 >  >  But before going further, I would like to know if it seems to 
you

 a
 >  >  good way to have Oracle support available by default in any 
OSGeo

 software

 The OSGeo4W and Tamasz packages solutions are working pretty well 
for
 Windows users, so far. For QGIS all you have to do is to enable the 
Oracle
 Raster driver, is you want to use GeoRaster. Works pretty fast if 
the image
 has overviews. Please note that other OSGeo and commercial software 
can

 also access Oracle Spatial through GDAL.


 >  >  Depending of your answers, I 'll come back to ask you how
 it's the
 >  >  best way to do that ?

 I hope that would answer your question.

 Regards,

 Ivan


 --
 Vincent Rogier

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[Andreas Neumann]

Hi Tamas,

That would be interesting. So the user could specify a folder with 
images and GDAL would create an OGR layer that would expose the photo 
location? The OGR feature would have certain EXIF data exposed as 
attributes?


If you work on this, could you also expose other EXIF data, such as the 
viewpoint coordinates, the image direction, the FOV or focal length, the 
sensor size, etc. - this information could be used to create a field of 
view angle of the picture.


You can try this at http://www.geofoto.ch/geophotomap/index.svg where 
you can click on a picture standpoint and the browser will display an 
angle where the picture is looking at.


I'd be interested in such a provider, as it would open a lot of 
possibilities to display photo information in various applications.


Are you aware of EXIFTOOL - the perl-script that allows getting and 
setting image metadata, such as EXIF, IPTC, XMP, etc.? See 
http://www.sno.phy.queensu.ca/~phil/exiftool/ - it is sort of the Swiss 
Army Knife of photo metadata and one of the fewer apps that can also set 
metadata - not just read.


Andreas

On Mon, 23 Jul 2012 09:51:14 +0200, Tamas Szekeres wrote:

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. 

Best regards,

Tamas


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Open DXF issues when writing

[Andreas Neumann]

Hi,

The current ogr version seems to be quite broken when it comes to 
writing DXF files.


See bug report at:

http://trac.osgeo.org/gdal/ticket/4680 (Invalid DXF files)

and maillist threads:
http://lists.osgeo.org/pipermail/gdal-dev/2012-July/04.html
und
http://lists.osgeo.org/pipermail/gdal-dev/2012-June/033036.html

I wonder if someone would be able to fix these problems?

Thank you for your reply if this can be fixed with a reasonable effort 
or with an estimate how much it would cost.


Andreas

--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Shifting raster image one meter

[Andreas Neumann]

Hi,

just wanted you to know that gdal_edit.py worked perfectly fine:

Here is my command:
gdal_edit.py -a_ullr 688999 252000.25 702999 241000.25 
orthofoto_2010.tif


where -a_ullr are the new upper left and the lower right corner 
coordinates.


Thanks for the hint!

Andreas

On Mon, 09 Jan 2012 17:23:17 +0100, Jean-Claude Repetto wrote:

Le 09/01/2012 17:06, Andreas Neumann a écrit :


Should I edit the world file? The image is a geotiff, so it doesn't 
have

a worldfile.

Thanks for any ideas.

Andreas



Hi,

You can use the new utility gdal_edit.py (in GDAL 1.9) to edit
GeoTiff metadata.

Frank, Even : It would be useful to add this utility to the
documentation page at http://www.gdal.org/gdal_utilities.html .

Jean-Claude

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Shifting raster image one meter

[Andreas Neumann]

Thanks, Jean-Claude,

I will give it a try tomorrow!

Andreas

On Mon, 09 Jan 2012 17:23:17 +0100, Jean-Claude Repetto wrote:

Le 09/01/2012 17:06, Andreas Neumann a écrit :


Should I edit the world file? The image is a geotiff, so it doesn't 
have

a worldfile.

Thanks for any ideas.

Andreas



Hi,

You can use the new utility gdal_edit.py (in GDAL 1.9) to edit
GeoTiff metadata.

Frank, Even : It would be useful to add this utility to the
documentation page at http://www.gdal.org/gdal_utilities.html .

Jean-Claude

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Shifting raster image one meter

[Andreas Neumann]

Hi,

Due to some error that I cannot easily reproduce one orthoimage is one 
meter offset. Luckily the shift is constant throughout the image.


What is the easiest way to shift this image back one meter (east-west) 
with gdal utilities? I browsed through the gdal_translate and gdal_warp 
documentation but couldn't find an easy way to translate an image 
without changing the projection.


Should I edit the world file? The image is a geotiff, so it doesn't 
have a worldfile.


Thanks for any ideas.

Andreas

--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Enhancements to ORG DXF Driver

[Andreas Neumann]

Hi Stefan,

I am not a developer, but only a user that has to deal with DXF export 
and import from time to time.


From a user perspective I would like to see this included - thank you 
for taking the time to document and write the patch!


Andreas

On Mon, 5 Dec 2011 22:50:16 +0100, Stefan Röckelein wrote:

Hi all,

I am using GDAL/OGR since about one year for the viewing of DXF files
in two different programs. Since then I have added some enhancements
in the DXF driver of OGR. Because it is very tedious to change all 
the

enhancements all the time a new version of GDAL is out and because I
want to contribute my enhancements to the community I have opened a
ticket with all my enhancements:

http://trac.osgeo.org/gdal/ticket/4369 [1]

A little bit about myself. As a civil engineer and I have worked a 
lot

with AutoCAD. A few years ago I changed changed my occupation and
started working as a self employed software developer. At the moment
I'm also about to finish a Master's degree in Geodesy and
Geoinformation Science in Berlin. Therefore, in the future I might
have more contributions for GDAL/OGR.

Stefan Röckelein


Links:
--
[1] http://trac.osgeo.org/gdal/ticket/4369


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Re: Problem converting certain postgis tables to spatialite

[Andreas Neumann]

HI Jukka,

Thank you for your thoughts. Yes, perhaps I should use update instead 
of append.


I actually found out what the problem is:

Tables or views that do not have an entry in public.geometry_columns 
(the postgis metadata table) cause the segmentation fault. Once the 
entry is there, it converts fine.


Perhaps ogr2ogr could issue a warning or error message in this case 
instead of segfaulting. It would be nicer.


Thanks again,
Andreas

On Wed, 7 Sep 2011 14:52:31 + (UTC), Jukka Rahkonen wrote:

Andreas Neumann  carto.net> writes:



 Hi,

 I am converting several tables from Postgis to SpatiaLite using
 ogr2ogr.

 Here is my command:

 ---
 ogr2ogr -append -lco LAUNDER=yes -lco SPATIAL_INDEX=yes -nln
 av_grenzpunkte -f SQLite uster.sqlite PG:"dbname='mydb' 
host='myserver'

 port='5432' user='username' password='pw' schemas=av_user
 tables=grenzpunkte(the_geom)"
 --


Hi,

I have used these options:

-dsco SPATIALITE=yes
-lco SPATIAL_INDEX=no
and for polygon layers
-nlt MULTIPOLYGON (Spatialite do not want polygons and multipolygons
on the same
layer, so let them be all multipolygons). Same with mixed 
lines/multilines if

you may have those.

-update is needed when adding new layers. Are you adding to an 
existing table

because you have -append?

Ogr2ogr does not create totally valid Spatialite databases. Therefore
I skip the
SPATIAL_INDEX because conversion is faster without. After ogr2ogr
process I am
cleaning the resulting database by copying the tables into a fresh 
Spatialite

database with OpenLite tool http://www.gaia-gis.it/OpenLite/

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Problem converting certain postgis tables to spatialite

[Andreas Neumann]

Hi,

I am converting several tables from Postgis to SpatiaLite using 
ogr2ogr.


Here is my command:

---
ogr2ogr -append -lco LAUNDER=yes -lco SPATIAL_INDEX=yes -nln 
av_grenzpunkte -f SQLite uster.sqlite PG:"dbname='mydb' host='myserver' 
port='5432' user='username' password='pw' schemas=av_user 
tables=grenzpunkte(the_geom)"

--

The problem is that about 50% of the tables convert fine, while the 
other half ends with a segmentation fault. I don't see a pattern yet why 
some convert fine, while others do not.


I am using Ubuntu 64bit, latest trunk and libspatialite 2.3.1

Do you have any idea how I can find out what the problem is with the 
tables that do not convert? Any experiences with similar behavior and 
how to solve it?


Thanks,
Andreas

--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Using GDAL OGR DXF driver to export complex DXF Blocks from Kosmo (OpenJUMP)

[Andreas Neumann]

Hi,

I don't know about Kosmo or OpenJump, but OGR supports export of 
blocks. You would have to specify a separate template drawing containing 
the block definitions.


Your input data would have to contain a column named "blockname", and 
optionally columns "blockscale" and "blockangle".


blockname is a string corresponding to the block definitions in the 
separate dxf template containing the block definitions, blockscale is in 
syntax "(1,1,1)" for scaling in all three dimensions - "(1,1,1)" 
actually does not scale as you would assume. block angle is in degrees I 
think - I don't know which direction (clock-wise or anticlockwise and 
starting point).


I successfully use OGR to convert a Postgis View to DXF on the command 
line. This is for a waste-water network where we use blocks to symbolize 
different manhole types. Here is the command I use:


ogr2ogr -f DXF test_ogr.dxf -dsco 
header=header_export_werkplan_abwasser.dxf -spat 695700 245900 696000 
246100 PG:"dbname='dbname' host='hostname' port='5432' user='www' 
password='xxx' schemas=abwasser 
tables=abwasser.export_dxf_geo405(the_geom)"


Hope this helps,

Andreas

On Wed, 17 Aug 2011 05:58:07 -0700 (PDT), rawcofe wrote:

Hello,

I'm wondering is it possible to use ogr dxf driver for exporting 
features as
blocks in DXF format from Kosmo which is built on OpenJUMP framework? 
I have
read (http://www.gdal.org/ogr/drv_dxf.html) that ogr dxf driver 
supports
reading and writing of DXF blocks. Is the DXF driver completely 
functional
considering block export and can be used with OpenJUMP as is or it 
requires

a considerable amount of development effort to implement? Where can I
download this driver and does it have some licensing issues if I try 
to

integrate it with Kosmo?

Thank you for your help,
rawcofe

--
View this message in context:

http://osgeo-org.1803224.n2.nabble.com/Using-GDAL-OGR-DXF-driver-to-export-complex-DXF-Blocks-from-Kosmo-OpenJUMP-tp6695304p6695304.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


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Commit Access for Paul Ramsey

[Andreas Neumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

+1

Looking forward to Pauls contributions.

Andreas

On 07/20/2011 11:11 PM, Even Rouault wrote:
> Motion: Extend GDAL/OGR Commit Access to Paul Ramsey
> 
> ---
> 
> Hi,
> 
> Paul, who has been involved for many years in the developement of various 
> OSGeo projects like PostGIS or MapServer, has recently contributed in the 
> developement of the OGR FileGDB driver. I have applied on his behalf various 
> patches he has submitted to Trac (*). His area of interest would also cover 
> the OGR PG driver for which he has also contributed an enhancement recently.
> 
> It would be convenient to give him direct commit access to subversion.
> 
> Paul, could you reply to this message indicating your agreement to the
> guidelines listed in:
> 
> http://trac.osgeo.org/gdal/wiki/rfc3_commiters
> 
> I'll start voting with my support:
> 
> +1
> 
> Best regards,
> 
> Even
> 
> (*) See http://trac.osgeo.org/gdal/search?q=FGDB&noquickjump=1&ticket=on
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOJ0YuAAoJELiCsGDopvBCfssH/0D6FdZjvz+9x9tOMXRhidTh
41O0IHbmvtU+1TpIbWJBOTynZJKASKLI57GBq95U9o6Q5WDj0b5F3kkuBTtsMnQU
62jXmE14Q9nHBjeWPjzx0zQW4sDYJPw3WqzvSpQWbvWr+47GzkKWuZwae+WJbfWm
HXOlg/EDqyMo9GrqClq37EOPtVjMoN8Z1LH8ewvY7sv59gaInXtYluH+VfBVbJAA
Af0hIOefKont/yyv9FjJg+m5CgWChsbZVFXuKY+JwGdMzwmA2cjx5yqPX24Jsmc+
jx43TxLwYum0eUwM7BwL7wlNr9crJNo/QC2qbJJi+Ti0ab9Kvnxpguk0xsnQoI4=
=u5Qx
-END PGP SIGNATURE-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compile problems: gdal-svn with geos-svn

[Andreas Neumann]

Hi,

Thanks - it works if I compile --without-libtool

Whats the drawback of not including libtool? I do not understand 
whether it is important/necessary.


Thanks,
Andreas

On Thu, 14 Jul 2011 18:33:31 +0200, Even Rouault wrote:

Selon Andreas Neumann :


 Hi,

 I tried to compile the most-recent gdal-svn with the most recent
 geos-svn and got the following error message during compilation:

 /bin/grep: /usr/lib/libgeos_c.la: No such file or directory
 /bin/sed: can't read /usr/lib/libgeos_c.la: No such file or 
directory
 libtool: link: `/usr/lib/libgeos_c.la' is not a valid libtool 
archive

 make[1]: *** [libgdal.la] Error 1
 make[1]: Leaving directory `/home/an/dev/cpp/gdal'
 make: *** [check-lib] Error 2

 Also, i pointed gdal to geos in /usr/local/lib, not in /usr/lib 
with

 the configure params.


It might be that there's some -L/usr/lib that found its way in the
linking line,
due to another unrelated lib located there.

I somehow remember having being caught by this libgeos_c.la issue,
and I believe
I just renamed that file to something else. An alternative would be 
to build

GDAL --without-libtool.



 Do you have any idea on how I can resolve the issue?

 Here are my configure params:

 ./configure --with-python --with-curl --with-expat
 --with-libtiff=internal --with-geos=/usr/local/bin/geos-config
 --with-pg=/usr/local/pgsql/bin/pg_config --with-xerces
 --with-oci-lib=/usr/local/lib/instantclient_10_2
 --with-oci-include=/usr/local/lib/instantclient_10_2/sdk/include
 --with-mysql --with-jpeg=internal --with-sqlite --with-spatialite
 --with-grass=/usr/local/grass-6.4.0RC5/

 Thanks,
 Andreas

--
 --
 Andreas Neumann
 Böschacherstrasse 10A
 8624 Grüt (Gossau ZH)
 Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Compile problems: gdal-svn with geos-svn

[Andreas Neumann]

Hi,

I tried to compile the most-recent gdal-svn with the most recent 
geos-svn and got the following error message during compilation:


/bin/grep: /usr/lib/libgeos_c.la: No such file or directory
/bin/sed: can't read /usr/lib/libgeos_c.la: No such file or directory
libtool: link: `/usr/lib/libgeos_c.la' is not a valid libtool archive
make[1]: *** [libgdal.la] Error 1
make[1]: Leaving directory `/home/an/dev/cpp/gdal'
make: *** [check-lib] Error 2

Also, i pointed gdal to geos in /usr/local/lib, not in /usr/lib with 
the configure params.


Do you have any idea on how I can resolve the issue?

Here are my configure params:

./configure --with-python --with-curl --with-expat 
--with-libtiff=internal --with-geos=/usr/local/bin/geos-config 
--with-pg=/usr/local/pgsql/bin/pg_config --with-xerces 
--with-oci-lib=/usr/local/lib/instantclient_10_2 
--with-oci-include=/usr/local/lib/instantclient_10_2/sdk/include 
--with-mysql --with-jpeg=internal --with-sqlite --with-spatialite 
--with-grass=/usr/local/grass-6.4.0RC5/


Thanks,
Andreas

--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL/OGR 1.8.0 Released

[Andreas Neumann]

Thanks to all on the gdal/ogr team who worked hard to make this release 
happen!


gdal/ogr is getting better and better and is one of the most important 
corner stones of Open Source GIS! The rapid success of Open Source 
Desktop and Web-GIS (like QGIS, gvSIG, OpenLayers, and to a certain 
extent also GRASS) is only possible because of the very good base libraries.


Congrats,
Andreas

On 1/23/11 5:25 PM, Frank Warmerdam wrote:

On behalf of the GDAL/OGR development team and community, I am pleased to
announce the release of GDAL/OGR 1.8.0.  GDAL/OGR is a C++ geospatial
data access library for raster and vector file formats, databases and
web services.  It includes bindings for several languages, and a variety
of command line tools.

  http://www.gdal.org/

The 1.8.0 release is a major new feature release with the following
highlights:

 * New GDAL drivers : GTX, HF2, JPEGLS, JP2OpenJPEG, JPIPKAK,
  KMLSUPEROVERLAY, LOS/LAS, MG4Lidar, NTv2,
  OZI, PDF, RASDAMAN, XYZ
 * New OGR drivers : AeronavFAA, ArcObjects, GPSBabel, HTF, LIBKML,
 MSSQLSpatial, NAS, OpenAir, PDS, PGDump, SOSI, 
SUA, WFS

 * Significantly improved OGR drivers : DXF, GML
 * New implemented RFCs:
   - RFC 7: Use VSILFILE for VSI*L Functions
   - RFC 24: Progressive data support in GDAL
   - RFC 28: OGR SQL Generalized Expressions
   - RFC 29: OGR Set Ignored Fields
   - RFC 30: Unicode Filenames
   - RFC 33: GTIFF - Corrected PixelIsPoint Interpretation
 * New utility : gdallocationinfo

More complete information on the new features and fixes in the 1.8.0
release can be found at:

  http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News

Source code, documentation and the test suite can be downloaded from:

 http://download.osgeo.org/gdal/gdal180.zip - source as a zip
 http://download.osgeo.org/gdal/gdal-1.8.0.tar.gz - source as .tar.gz
 http://download.osgeo.org/gdal/gdalautotest-1.8.0.tar.gz - test suite
 http://download.osgeo.org/gdal/gdal180doc.zip - docs / web site

Best regards,


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: DXF writing and layers

[Andreas Neumann]

Hi again,

I am wondering if most of my issues are a result of wrong parameters in my
ogr2ogr command:

Here is my command:

ogr2ogr -select '' -f DXF test_ogr.dxf -dsco
header=header_export_werkplan_abwasser.dxf -spat 695700 245900 696000
246100 PG:"dbname='uster' host='servername' port='5432' user='read'
password='reader' schemas=abwasser
tables=abwasser.export_dxf_geo405(the_geom)"

So maybe the -select '' causers ogr to not read the attribute values and
thus it cannot see layer, blockname, etc.?

That's probably the case.

If I use
ogr2ogr -f DXF test_ogr.dxf -dsco
header=header_export_werkplan_abwasser.dxf -spat 695700 245900 696000
246100 PG:"dbname='uster' host='servername' port='5432' user='read'
password='reader' schemas=abwasser
tables=abwasser.export_dxf_geo405(the_geom)"

note - without the -select '' I receive error messages:

ERROR 1: DXF layer does not support arbitrary field creation, field
'blockscale' not created.
ERROR 1: DXF layer does not support arbitrary field creation, field
'blockangle' not created.
ERROR 1: DXF layer does not support arbitrary field creation, field
'layer_geo405' not created.
ERROR 1: DXF layer does not support arbitrary field creation, field
'ogr_style' not created.
ERROR 1: DXF layer does not support arbitrary field creation, field 'gid'
not created.
ERROR 1: DXF layer does not support arbitrary field creation, field
'blockname' not created.

I still get an output dxf - but as soon as I open it in autocad, Autocad
crashes with a fatal error. FME can't read the resulting file either.

Andreas


On Wed, November 3, 2010 11:53 pm, Frank Warmerdam wrote:
> On Mon, Nov 1, 2010 at 6:52 AM, Andreas Neumann 
> wrote:
>> While testing the writer I wanted to use the new feature of specifying a
>> column in the source dataset that contains the layer name a feature
>> should
>> end up in the destination dxf file.
>>
>> My source is a Postgis table, and the layer name is stored in a column
>> called "layer".
>>
>> I don't know the correct dataset creation option (dsco) or layer
>> creation
>> option (lco) to specify the column containing the layernames.
>>
>> I tried:
>>
>> -dsco LayerName=layer
>> -dsco layer=layer
>> -lco LayerName=layer
>> -lco layer=layer
>>
>> But no matter which of the above options I try, all my features end up
>> in
>> layer "0".
>>
>> If anyone has a hint how I could issue the ogr2ogr command so I can
>> specify the layer a feature should end up in, it would be much
>> appreciated!
>
> Andreas,
>
> Currently the dxf writer only looks for the attribute named Layer
> to identify the layer name.  It sounds like in your case it should
> work directly since the Postgres column name is also "layer".
>
> If it is not, please file a ticket and I'll dig into it.  Providing
> an input dataset to demonstrate the problem would be
> helpful.
>
> Best regards,
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: DXF writing and layers

[Andreas Neumann]

Hi Frank,

It seems that even if the layers are present in the header.dxf file, still
everything ends up in layer "0".

Again - hopefully my test data will shed some light on the problem.

Andreas

On Wed, November 3, 2010 11:53 pm, Frank Warmerdam wrote:
> On Mon, Nov 1, 2010 at 6:52 AM, Andreas Neumann 
> wrote:
>> While testing the writer I wanted to use the new feature of specifying a
>> column in the source dataset that contains the layer name a feature
>> should
>> end up in the destination dxf file.
>>
>> My source is a Postgis table, and the layer name is stored in a column
>> called "layer".
>>
>> I don't know the correct dataset creation option (dsco) or layer
>> creation
>> option (lco) to specify the column containing the layernames.
>>
>> I tried:
>>
>> -dsco LayerName=layer
>> -dsco layer=layer
>> -lco LayerName=layer
>> -lco layer=layer
>>
>> But no matter which of the above options I try, all my features end up
>> in
>> layer "0".
>>
>> If anyone has a hint how I could issue the ogr2ogr command so I can
>> specify the layer a feature should end up in, it would be much
>> appreciated!
>
> Andreas,
>
> Currently the dxf writer only looks for the attribute named Layer
> to identify the layer name.  It sounds like in your case it should
> work directly since the Postgres column name is also "layer".
>
> If it is not, please file a ticket and I'll dig into it.  Providing
> an input dataset to demonstrate the problem would be
> helpful.
>
> Best regards,
> --
> ---+----------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: DXF Writer and labels: encoding, angle and anchor position?

[Andreas Neumann]

Hi Frank,

Regarding the encoding:

It seems like ogr2ogr just writes everything out as UTF-8. My data source
(postgres database) is also utf-8. Autocad and FME however, don't like the
utf-8 encoding. They probably expect some Windows encoding (either
ISO-8859-15 or Latin 1 or whatever Windows uses by default). However, I
can't provide any hard facts on this. Is there some information about
encoding in the dxf specification?

I still can't get label angles to work and I can't test the symbol angles
yet, because I can't get my own blocks to display.

It seems like ogr2ogr inserts the block definitions (I can see them in the
output file), but they either aren't properly inserted or referenced. When
I go into the block editor in autocad I can only see the block definition
of the first block.

Again - I will send the header.dxf and provide a bug report.

Thanks,
Andreas

On Thu, November 4, 2010 12:14 am, Frank Warmerdam wrote:
> On Mon, Nov 1, 2010 at 10:19 AM, Andreas Neumann 
> wrote:
>> Hi,
>>
>> Again some question on the dxf-writer, now with regards to labels:
>>
>> * some of my special characters don't display correctly, e.g. the
>> Unicode
>> 2030 sign (german Promille sign) doesn't display (neither in the FME
>> viewer nor in Autocad Design Review) - some other "strange characters"
>> are
>> displayed instead. Do I have to set an encoding for the target dxf? My
>> source Postgis table is in UTF-8.
>
> Andreas,
>
> Hmm, encoding in DXF is not something I have given any
> consideration to so far.  The PostGIS driver should be
> returning the text in utf-8, but I do nothing special to
> process text read or written from/to DXF.  I ought to be.
>
> Could you file a ticket on this issue?  It would be helpful
> to include a small example DXF created with autocad that
> does display the character(s) in question properly and then
> an example of what happens with OGR.
>
>> * should label angle work? (in my case it doesn't)
>
> I have confirmed that when trying to write MTEXT
> entities the style string is checked for angle and
> trying to write it.  There might be problems with this
> though I thought it was working in my test suite.  If
> you file a ticket, with example input I will dig into the
> details.
>
>> * should anchor position work?
>
> Yes, it should.  There is code to translate the anchor.
> If it isn't working please file a ticket.
>
>> Here is an example OGR feature-style that I am testing:
>>
>> LABEL(f:"Cadastra Cn,Arial",s:1.5g,t:"PVC 150
>> -6.96-",c:#FF,a:72,p:3)
>>
>> In the above example, the label angle does not work - I am unsure about
>> the anchor position.
>
> Best regards,
> --
> -----------+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: dxf writer: specifying dash patterns with ogr-feature styles

[Andreas Neumann]

Hi Frank,

I changed the delimiters to a space but the dashed lines still show up as
continuous lines in Autocad or FME viewer.

I will provide test-data and file a bug.

Thanks a lot,
Andreas

On Wed, November 3, 2010 11:59 pm, Frank Warmerdam wrote:
> On Mon, Nov 1, 2010 at 7:01 AM, Andreas Neumann 
> wrote:
>> Hi again,
>>
>> Another problem with the DXF writer:
>>
>> I am trying to specify a dash-patterns for lwpolylines by using the
>> following OGR feature styling:
>>
>> PEN(c:#FF,p:"2g,1g") - the pattern is defined in ground units, the
>> ground units in the data sets are set in meters.
>
> Andreas,
>
> I believe the problem is that you are using a comma as a delimiter
> instead of a space.  The pattern tokenizer looks for white space,
> according to the OGR feature style specification.
>
> Best regards,
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: DXF writing and layers

[Andreas Neumann]

Hi Frank,

Still no luck here with the layers.

Just to be sure: the layers aren't present in the header file. They should
be created by ogr. Is this correct that I don't necessarily have to create
the layers in advance?

Well - I think I will report a bug and make you the data available that I
am testing with.

Thanks a lot,
Andreas

On Wed, November 3, 2010 11:53 pm, Frank Warmerdam wrote:
> On Mon, Nov 1, 2010 at 6:52 AM, Andreas Neumann 
> wrote:
>> While testing the writer I wanted to use the new feature of specifying a
>> column in the source dataset that contains the layer name a feature
>> should
>> end up in the destination dxf file.
>>
>> My source is a Postgis table, and the layer name is stored in a column
>> called "layer".
>>
>> I don't know the correct dataset creation option (dsco) or layer
>> creation
>> option (lco) to specify the column containing the layernames.
>>
>> I tried:
>>
>> -dsco LayerName=layer
>> -dsco layer=layer
>> -lco LayerName=layer
>> -lco layer=layer
>>
>> But no matter which of the above options I try, all my features end up
>> in
>> layer "0".
>>
>> If anyone has a hint how I could issue the ogr2ogr command so I can
>> specify the layer a feature should end up in, it would be much
>> appreciated!
>
> Andreas,
>
> Currently the dxf writer only looks for the attribute named Layer
> to identify the layer name.  It sounds like in your case it should
> work directly since the Postgres column name is also "layer".
>
> If it is not, please file a ticket and I'll dig into it.  Providing
> an input dataset to demonstrate the problem would be
> helpful.
>
> Best regards,
> --
> ---+----------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] DXF Writer and labels: encoding, angle and anchor position?

[Andreas Neumann]

Hi,

Again some question on the dxf-writer, now with regards to labels:

* some of my special characters don't display correctly, e.g. the Unicode
2030 sign (german Promille sign) doesn't display (neither in the FME
viewer nor in Autocad Design Review) - some other "strange characters" are
displayed instead. Do I have to set an encoding for the target dxf? My
source Postgis table is in UTF-8.

* should label angle work? (in my case it doesn't)

* should anchor position work?

Here is an example OGR feature-style that I am testing:

LABEL(f:"Cadastra Cn,Arial",s:1.5g,t:"PVC 150 -6.96-",c:#FF,a:72,p:3)

In the above example, the label angle does not work - I am unsure about
the anchor position.

Thanks for any hints or info, if any of the above should be implemented or
if I am doing something wrong in my OGR feature-styling.

Andreas

-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] dxf writer: specifying dash patterns with ogr-feature styles

[Andreas Neumann]

Hi again,

Another problem with the DXF writer:

I am trying to specify a dash-patterns for lwpolylines by using the
following OGR feature styling:

PEN(c:#FF,p:"2g,1g") - the pattern is defined in ground units, the
ground units in the data sets are set in meters.

In the resulting dxf I can see the line as red (as specified), but the
dash-pattern (dash of 2m and gap of 1m) does not appear.

Anyone knows on what may be wrong that the dash-pattern is not applied?

Thanks,
Andreas

-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] DXF writing and layers

[Andreas Neumann]

Hi,

I am further testing the enhanced DXF reader/writer.

While testing the writer I wanted to use the new feature of specifying a
column in the source dataset that contains the layer name a feature should
end up in the destination dxf file.

My source is a Postgis table, and the layer name is stored in a column
called "layer".

I don't know the correct dataset creation option (dsco) or layer creation
option (lco) to specify the column containing the layernames.

I tried:

-dsco LayerName=layer
-dsco layer=layer
-lco LayerName=layer
-lco layer=layer

But no matter which of the above options I try, all my features end up in
layer "0".

If anyone has a hint how I could issue the ogr2ogr command so I can
specify the layer a feature should end up in, it would be much
appreciated!

Thanks,
Andreas


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] mod_python issue with libtiff

[Andreas Neumann]

Hi,

Thank you all for your hints so far.

Frank also suggested to examine which libraries are in use by Apache with
the following command:

cat /proc//maps

It turns out that
/usr/lib/libtiff.so.4.3.2
and
/usr/local/lib/libtiff.so.5.0.0

are in use.

There is no libtiff.so.3x installed in the system.

So I wonder if the error message mentioning 3x and 4x actually means 4x
and 5x?


I also tried mod_wsgi instead of mod_python, but the same error message
appears.

After looking at all the libraries that are used by Apache I also saw that
GRASS was included. Next, I compiled gdal without GRASS support - and
voila - mod_wsgi and mod_python worked.

My GRASS installation was fairly old and I don't need it on this server
currently. My guess is that GRASS somehow linked to libtiff4x and the rest
of gdal linked to libtiff5x. Or maybe GRASS links to libtiff3x which isn't
present in my system anymore? I also guess that compiling GRASS again
would solve the problem.

Although I still don't fully understand the output of
/proc//maps, it is cool being able to look at the libraries
that a process is using.

Thanks for all of your hints. Problem is solved now.

Andreas


On Fri, October 15, 2010 8:32 pm, Even Rouault wrote:
> Andreas,
>
> I'm somehow happy to see that you've hit the warning. It means that it was
> usefull to add it and probably saved you headaches when things would have
> started to crash awfully...
>
> Now, I'm afraid I cannot really help you more. There's something in your
> Apache that loads a libtiff 3.X... Don't you load other modules that could
> load
> libtiff indirectly ? A "ld foo.so | grep libtiff" on the potential .so
> python
> modules might help find the culprit.
>
> Or perhaps if you move/rename /usr/lib/libtiff.so* to something else, the
> culprit will complain and you'll be able to identify it.
>
> Le vendredi 15 octobre 2010 17:26:13, Andreas Neumann a écrit :
>> Hi,
>>
>> I recently upgraded my gdal version to the recent SVN version. The
>> command-line tools work fine, but my python scripts inside Apache
>> mod_python fail with the following error:
>>
>> -
>>
>> ERROR 1: WARNING ! libtiff version mismatch : You're linking against
>> libtiff 3.X but GDAL has been compiled against libtiff >= 4.0.0
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] mod_python
>> (pid=2117, interpreter='srv139.stadt-uster.ch', phase='PythonHandler',
>> handler='mod_python.publisher'): Application error
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] ServerName:
>> 'srv139.stadt-uster.ch'
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] DocumentRoot:
>> '/home/www/www/'
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] URI:
>> '/geodatenshop/extract_meta.py/raster'
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] Location: None
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] Directory: '/'
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] Filename:
>> '/home/www/www/geodatenshop/extract_meta.py'
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] PathInfo:
>> '/raster' [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]
>> Traceback (most recent call last):
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
>> "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1537, in
>> HandlerDispatch\ndefault=default_handler, arg=req,
>> silent=hlist.silent)
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
>> "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1229, in
>> _process_target\nresult = _execute_target(config, req, object, arg)
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
>> "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1128, in
>> _execute_target\nresult = object(arg)
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
>> "/usr/lib/python2.6/dist-packages/mod_python/publisher.py", line 213, in
>> handler\npublished = publish_object(req, object)
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
>> "/usr/lib/python2.6/dist-packages/mod_python/publisher.py", line 425, in
>> publish_object\nreturn publish_object(req,util.apply_fs_data(object,
>> req.form, req=req))
>> [Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
>> "/usr/lib/python2.6/dist-packages/mod_python/util.py", line 55

[gdal-dev] mod_python issue with libtiff

[Andreas Neumann]

Hi,

I recently upgraded my gdal version to the recent SVN version. The
command-line tools work fine, but my python scripts inside Apache
mod_python fail with the following error:

-

ERROR 1: WARNING ! libtiff version mismatch : You're linking against
libtiff 3.X but GDAL has been compiled against libtiff >= 4.0.0
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] mod_python
(pid=2117, interpreter='srv139.stadt-uster.ch', phase='PythonHandler',
handler='mod_python.publisher'): Application error
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] ServerName:
'srv139.stadt-uster.ch'
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] DocumentRoot:
'/home/www/www/'
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] URI:
'/geodatenshop/extract_meta.py/raster'
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] Location: None
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] Directory: '/'
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] Filename:
'/home/www/www/geodatenshop/extract_meta.py'
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] PathInfo: '/raster'
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] Traceback (most
recent call last):
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
"/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1537, in
HandlerDispatch\ndefault=default_handler, arg=req,
silent=hlist.silent)
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
"/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1229, in
_process_target\nresult = _execute_target(config, req, object, arg)
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
"/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1128, in
_execute_target\nresult = object(arg)
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
"/usr/lib/python2.6/dist-packages/mod_python/publisher.py", line 213, in
handler\npublished = publish_object(req, object)
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
"/usr/lib/python2.6/dist-packages/mod_python/publisher.py", line 425, in
publish_object\nreturn publish_object(req,util.apply_fs_data(object,
req.form, req=req))
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
"/usr/lib/python2.6/dist-packages/mod_python/util.py", line 554, in
apply_fs_data\nreturn object(**args)
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198]   File
"/home/www/www/geodatenshop/extract_meta.py", line 18, in raster\n   
req.write('\\t'+dataset.GetDriver().ShortName+'/'+dataset.GetDriver().LongName+'\\n')
[Fri Oct 15 17:03:22 2010] [error] [client 10.63.238.198] AttributeError:
'NoneType' object has no attribute 'GetDriver'

--

I set the libtiff to "internal" in the configure options before the compile.

I don't understand why the mod_python scripts link to libtiff 3.x. Why are
the commandline tools (gdal-info, gdal-translate, gdal_merge.py, etc.)
working fine, but the scripts inside mod_python do not.

Both are using python2.6.

Thank you very much for any pointers or hints on what may be wrong in my
configuration.

Andreas


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] No Interlis format support after recent svn update

[Andreas Neumann]

Hi Even,

Thank you for your hints. It seems to work again. From all of your
suggestions it was most likely the make clean in ogr/ogrsf_frmts/ili. I
think all other things were fine (the HAVE_XERCES was set to yes,
ogr/ogrsf_frmts/ili existed).

Anyway, all fine now.

Thanks for your help,
Andreas

On Wed, August 11, 2010 7:11 pm, Even Rouault wrote:
> Well, interlis is listed for me with latest SVN, so I guess it must be
> some
> detail on your side.
>
> Did you do a full rebuild : 'make clean' and 'make' ?
>
> In GDALmake.opt, is HAVE_XERCES set to yes ?
>
> In the console, when compiling do you see that it goes into
> ogr/ogrsf_frmts/ili ? you can cd to that directore and make clean in it,
> and
> then retry a make from the top directory
>
> Le mercredi 11 août 2010 17:28:48, Andreas Neumann a écrit :
>> Hi,
>>
>> For some reasons, after an SVN update, I can't use the Interlis format
>> anymore. ogrinfo --formats doesn't list the Interlis 1/2 formats as
>> supported.
>>
>> Luckily I still have an older installation which I can use for my data
>> imports, but I would like to get it working again with the SVN version.
>>
>> What could be missing? Xerces is listed as supported by the configure
>> script and ili2c.jar is also present in /usr/bin or in the jvm/lib
>> directory.
>>
>> Any help/ideas would be much appreciated.
>>
>> Thanks,
>> Andreas
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] No Interlis format support after recent svn update

[Andreas Neumann]

Hi,

For some reasons, after an SVN update, I can't use the Interlis format
anymore. ogrinfo --formats doesn't list the Interlis 1/2 formats as
supported.

Luckily I still have an older installation which I can use for my data
imports, but I would like to get it working again with the SVN version.

What could be missing? Xerces is listed as supported by the configure
script and ili2c.jar is also present in /usr/bin or in the jvm/lib
directory.

Any help/ideas would be much appreciated.

Thanks,
Andreas

-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Save to DXF with specific layer name with c#

[Andreas Neumann]

Hi Colin,

Not sure if creation of layers is yet supported. I think it is only
supported if you created the layers in advance in the header.dxf file.

Frank Warmerdam is now working on a second round of improvements where
automatic layer creation (even if the layers aren't present in header.dxf)
should be supported.

You probably have to wait for a couple weeks for this to appear.

Frank can tell you more about it.

Andreas


On Fri, July 30, 2010 11:21 am, Colin Wright wrote:
> I'm using GDAL/OGR 1.7.2 with the C# bindings to write a tool that will
> export data to various formats.
>
> When it exports to DXF I want it to use a specific layer name rather than
> using the default dxf layer 0.
> The problem is that even though I'm setting the attribute "Layer" for each
> feature, it is still appearing as layer 0 in the final DXF file.  I've
> checked and the "Layer" attribute does exist, and setting the attribute
> value doesn't throw any errors.  The geometry is getting saved to the DXF
> OK.
>
> Any ideas?  An extract of my code is below.
>
> //--
> //Loop through input layers writing to output
> lyrInput.ResetReading();
> Feature inFeat = lyrInput.GetNextFeature();
> iError = -1;
> while (inFeat != null)
> {
>//Try approach of creating new feature
>   Feature outFeat = new Feature(lyrOutput.GetLayerDefn());
> if (outFeat.SetGeometry(inFeat.GetGeometryRef()) ==
> Ogr.OGRERR_NONE)
>{
>bFeatOK = true;
>
>   //Generic attribs for DXF
>   if (sOutFormat == "DXF")
>   {
>   //I've checked and this section is
> getting called
>   outFeat.SetField("Layer",
> "MyLayerName");
>
>}
>}
>if (bFeatOK)
>{
>iError = lyrOutput.CreateFeature(outFeat);
>}
>
>outFeat.Dispose();
>inFeat = lyrInput.GetNextFeature();
> }
>
>
> Thanks
>
> Colin
>
>
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OpenDWG, Open Design Alliance

[Andreas Neumann]

Hi Frank,

Thanks for the info - do you have a pointer to this OS DWG effort?

Andreas

On Tue, June 29, 2010 12:29 pm, Frank Warmerdam wrote:
> On Tue, Jun 29, 2010 at 12:23 PM, Andreas Neumann 
> wrote:
>> Hi,
>>
>> >From time to time it would be nice if I could read DWG files from
>> OS-GIS.
>>
>> OGR has the option to read DWG through the Open Design Alliance
>> DWGdirect
>> library - which is only available for registered users.
>>
>> For inhouse use it would be affordable for me to become a ODA member.
>>
>> Before I would try to do so - can I ask if someone on this list has
>> experiences with the library? Does it still work with the current gdal
>> trunk? Is it worth the efforts?
>
> Andreas,
>
> I have not attempted to maintain this driver for some time,
> and I suspect there have been changes in the dwgdirect
> library that may be a problem.  If you try it, I'm sure we would
> appreciate a report.
>
> I would also note there is a new open source dwg effort
> ongoing and that as that matures we might be able to
> utilize that.
>
> Best regards,
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] OpenDWG, Open Design Alliance

[Andreas Neumann]

Hi,

>From time to time it would be nice if I could read DWG files from OS-GIS.

OGR has the option to read DWG through the Open Design Alliance DWGdirect
library - which is only available for registered users.

For inhouse use it would be affordable for me to become a ODA member.

Before I would try to do so - can I ask if someone on this list has
experiences with the library? Does it still work with the current gdal
trunk? Is it worth the efforts?

I also see that DWGdirect is now Teigha? Is this just the new version of
DWGdirect? Would Teigha also work or would I need an older version of the
DWGdirect library?

Thanks if anyone has something to share in this respect.

Andreas


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] writing DWG/DXF

[Andreas Neumann]

Hi,

yes - it is a read/write driver.

Since there are so many dxf variations out there reading may not be 
supported for all files. Also there are some issues with reading (e.g. 
block references, maybe some text issues). Curves and Splines are 
segmented on reading the dxf. An application that reads dxf needs to be 
able to deal with multiple geometry formats at once - e.g. mixed 
linestrings/point/text/polygon.


DWG reading is not supported by this reader, since DWG is not well 
documented (at least not in the public) and a binary format.


It would be good if you could test and report issues.

Regarding writing:
* OGRFeatureStyling is supported partially (at least pen colors work, 
dashes I think not)

* currently there is no way to write to more than one layer
* again issues with block references

There will be further work on this provider. If you (or someone else) 
would have some money for improvements it would help as well.


Best,
Andreas

bart...@osgis.nl wrote:

Hi,

I believe it also writes:

http://svn.osgeo.org/gdal/trunk/gdal/ogr/ogrsf_frmts/dxf/drv_dxf.html

"DXF files are written in AutoCAD 2000 format."

Best regards,
Bart

  

Bart,

bart...@osgis.nl wrote:


there is a new driver that does not have this dependency:
http://fwarmerdam.blogspot.com/2009/12/ogr-dxf-driver.html
  

Thanks for pointing this out, I was not aware of the development. But
that is a read-only driver, is it not?

Bye
Frederik






___
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] pdf/svg -> shape

[Andreas Neumann]

one approach would be to go throug dxf. Quite a few graphics/drawing 
tools can export to dxf. QGIS can import dxf to shape using a plugin. 
You can then translate/scale the data for georeferencing.


I am sure there are other options as well.

Andreas

Steve Miller wrote:

Hi,

I have a pdf file that contains a vector image. I can get the data 
into an svg file using inkscape. Is there someway of getting this into 
a shape file or other usable GIS file of polylines? I really don't 
want to convert to a raster and have to digitize the data.


Any help would be appreciated.
Thanks,
Steve
___
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] Curve support in OGR

[Andreas Neumann]

Hi Frank,

Good to hear that you are principally interested in curve support. I can
understand that you are reluctanct to start such an effort before proper
financial backing.

Unfortunately I don't have loads of money to support such an effort, but I
(resp. my employer) would participate in a joint effort to financially
support this project.

It would be useful to have a clue how much work (and related estimated
development hours) would have to be invested. Also a list of major
milestones/packages would be useful.

Frank, do you think that you could write up a proposal/estimate? Others
could join in of course, but you are probably the one with the best
knowledge on the architecture of ogr.

Thanks,
Andreas


On Fri, June 19, 2009 4:44 pm, Frank Warmerdam wrote:
> Andreas Neumann wrote:
>> right - we still use an old commercial version of Mapguide. We may move
>> to
>> the newer open-source version (or Mapserver) in the future.
>>
>> But this is not my main concern. The main concern is being able to work
>> with curves (mainly circular arcs) across the whole OSGeo tool chain,
>> primarily also in Desktop GIS.
>>
>> Many desktop GIS build on top of OGR (e.g. the one we use: QGIS). They
>> won't bother with curves until their underlying base infrastructure
>> supports curves.
>>
>> I know it is a probably a huge effort to include curve support in OGR
>> and
>> won't happen tomorrow ... However, since more and more data formats and
>> applications now start to support curves, it would make sense that OGR
>> would support them as well, esp. since it is at the technical foundation
>> of so many other tools.
>>
>> I know it should be financially supported by the users, so I wonder if
>> we
>> could start a project like the WKTRaster project in Postgis [1], where
>> the
>> necessary work packages for curve support are laid out, as well as
>> potential programmers and sponsors. People/organizations can assign
>> themselves as sponsors for certain parts of the whole work then.
>>
>> The whole thing of course also concerns GEOS and Postgis.
>
> Andreas,
>
> I would like to upgrade OGR to support curves and generally to support
> a broader geometry model in line with Simple Features 1.1 and possible
> some of the ISO geometry types.  However, this is a substantial effort
> and I believe it would require financial support.  I have not had
> significant client interest in such an upgrade myself, nor have the GDAL
> sponsors spoken strongly on this point.
>
> So, I'm basically at the point of waiting for funded interest in the
> topic to grow.
>
> Best regards,
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
>
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Build OGR with Oracle support

[Andreas Neumann]

ok - the problem could now be solved by setting the library path in
/etc/ld.so.conf.d/oracle.conf and running ldconfig as root. Then all the
libraries could be found. Somehow the LD_LIBRARY_PATH variable was
constantly ignored, although it was set and could be queried with echo
$LD_LIBRARY_PATH. It was interesting that LD_LIBRARY_PATH worked as root,
but not as a regular user, but the method with ldconfig worked for all
users.

Thank you for all of your help!

Andreas


On Sun, June 21, 2009 9:55 pm, Andreas Neumann wrote:
> yes, my setup has nothing to do with fgs-dev
>
> This other path maybe appeared from the original email I was answering,
> but on my machine all the oracle instant client libraries are stored
> under /usr/local/lib/instantclient_10_2/ and the header files under
> /usr/local/lib/instantclient_10_2/sdk/
>
> I will try again on Monday, maybe with also setting the PATH variable.
>
> I will report back tomorrow.
>
> Andreas
>
> Normand Savard wrote:
>> Mateusz Loskot wrote:
>>> Andreas Neumann wrote:
>>>> /usr/bin/ld: warning: libnnz10.so, needed by
>>>> /usr/local/lib/instantclient_10_2/libclntsh.so, not found (try using
>>>>  -rpath or -rpath-link)
>>>
>>> The path above and the path below are different.
>>>
>>>>> -L/home/fgs/fgs-dev/built/instantclient_11_1 -lc\
>>>>> lntsh
>>>
>>> Are you sure you configure against one version of Oracle stuff?
>>> From what I can see, you have two versions.
>>>
>> Mateusz,
>>
>> Maybe I misinterpreted Andreas' email but I think he's trying to
>> compile GDAL/OGR with OCI (Oracle Instantclient) outside of fgs-dev.
>> Can you confirm Andreas?
>>
>> Norm
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Build OGR with Oracle support

[Andreas Neumann]

yes, my setup has nothing to do with fgs-dev

This other path maybe appeared from the original email I was answering, 
but on my machine all the oracle instant client libraries are stored 
under /usr/local/lib/instantclient_10_2/ and the header files under 
/usr/local/lib/instantclient_10_2/sdk/


I will try again on Monday, maybe with also setting the PATH variable.

I will report back tomorrow.

Andreas

Normand Savard wrote:

Mateusz Loskot wrote:

Andreas Neumann wrote:

/usr/bin/ld: warning: libnnz10.so, needed by
/usr/local/lib/instantclient_10_2/libclntsh.so, not found (try using
 -rpath or -rpath-link)


The path above and the path below are different.


-L/home/fgs/fgs-dev/built/instantclient_11_1 -lc\
lntsh


Are you sure you configure against one version of Oracle stuff?
From what I can see, you have two versions.


Mateusz,

Maybe I misinterpreted Andreas' email but I think he's trying to 
compile GDAL/OGR with OCI (Oracle Instantclient) outside of fgs-dev.  
Can you confirm Andreas?


Norm


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Build OGR with Oracle support

[Andreas Neumann]

t libnnz11.so library was not found.  I went to the
> instantclient directory but the library was present.  Since I use the
> fgs-dev environment the libraries are not in a traditional path so the
> linker could not find it.  To solve this issue, I added the path to
> where the library was installed to $LD_LIBRARY_PATH.  There was a
> problem with libaio.so.1 library.  For this particular issue I had to
> install libaio-dev on my system (Ubuntu:  apt-get install).
>
> It works fine after that.
>
> Thank you to both of you.
>
> Norm
>
>
>
> 1)config.log
> configure:23653: checking for Oracle OCI headers in
> /home/fgs/fgs-dev/built/ins\
> tantclient_11_1/sdk/include
> configure:23696: g++ -c -fPIC  -g -DDEBUG
> -I/home/fgs/fgs-dev/built/instantcli\
> ent_11_1/sdk/include conftest.cpp >&5
> configure:23702: $? = 0
> configure:23715: result: yes
> configure:23740: checking for Oracle OCI libraries in
> /home/fgs/fgs-dev/built/i\
> nstantclient_11_1
> configure:23743: result: norm:
> -L/home/fgs/fgs-dev/built/instantclient_11_1 -lc\
> lntsh
> configure:23745: result: norm:
> -I/home/fgs/fgs-dev/built/instantclient_11_1/sdk\
> /include
> configure:23781: g++ -o conftest -fPIC  -g -DDEBUG
> -I/home/fgs/fgs-dev/built/i\
> nstantclient_11_1/sdk/include
> -L/home/fgs/fgs-dev/built/instantclient_11_1 -lc\
> lntsh conftest.cpp -L/home/fgs/fgs-dev/built/jpeg
> -L/home/fgs/fgs-dev/built/jpe\
> g/lib -ljpeg -L/home/fgs/fgs-dev/built/libgeotiff/lib -lgeotiff
> -L/home/fgs/fgs\
> -dev/built/tiff/lib -ltiff -L/home/fgs/fgs-dev/built/libpng
> -L/home/fgs/fgs-dev\
> /built/libpng/lib -lpng -lpq -L/home/fgs/fgs-dev/built/postgresql/lib
> -lpq -lz \
> -L/home/fgs/fgs-dev/built/zlib -L/home/fgs/fgs-dev/built/zlib/lib  -lm
> -lrt -ld\
> l  >&5
> /usr/bin/ld: cannot find -lclntsh
> collect2: ld returned 1 exit status
> configure:23787: $? = 1
> configure: failed program was:
> |
> | /* confdefs.h.  */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
>
>
>
>
>
>
> 2) config.log
>
> configure:23740: checking for Oracle OCI libraries in
> /home/fgs/fgs-dev/built/i\
> nstantclient_11_1
> configure:23743: result: norm:
> -L/home/fgs/fgs-dev/built/instantclient_11_1 -lc\
> lntsh
> configure:23745: result: norm:
> -I/home/fgs/fgs-dev/built/instantclient_11_1/sdk\
> /include
> configure:23781: g++ -o conftest -fPIC  -g -DDEBUG
> -I/home/fgs/fgs-dev/built/i\
> nstantclient_11_1/sdk/include
> -L/home/fgs/fgs-dev/built/instantclient_11_1 -lc\
> lntsh conftest.cpp -L/home/fgs/fgs-dev/built/jpeg
> -L/home/fgs/fgs-dev/built/jpe\
> g/lib -ljpeg -L/home/fgs/fgs-dev/built/libgeotiff/lib -lgeotiff
> -L/home/fgs/fgs\
> -dev/built/tiff/lib -ltiff -L/home/fgs/fgs-dev/built/libpng
> -L/home/fgs/fgs-dev\
> /built/libpng/lib -lpng -lpq -L/home/fgs/fgs-dev/built/postgresql/lib
> -lpq -lz \
> -L/home/fgs/fgs-dev/built/zlib -L/home/fgs/fgs-dev/built/zlib/lib  -lm
> -lrt -ld\
> l  >&5
> /usr/bin/ld: warning: libnnz11.so, needed by
> /home/fgs/fgs-dev/built/instantcli\
> ent_11_1/libclntsh.so, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libaio.so.1, needed by
> /home/fgs/fgs-dev/built/instantcli\
> ent_11_1/libclntsh.so, not found (try using -rpath or -rpath-link)
> /home/fgs/fgs-dev/built/instantclient_11_1/libclntsh.so: undefined
> reference to\
>  `nzos_ServiceWriteQueue'
> /home/fgs/fgs-dev/built/instantclient_11_1/libclntsh.so: undefined
> reference to\
>  `nzosCipherSpecToStr'
> /home/fgs/fgs-dev/built/instantclient_11_1/libclntsh.so: undefined
> reference to\
>  `C_SetCRLBER'
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Curve support in OGR

[Andreas Neumann]

right - we still use an old commercial version of Mapguide. We may move to
the newer open-source version (or Mapserver) in the future.

But this is not my main concern. The main concern is being able to work
with curves (mainly circular arcs) across the whole OSGeo tool chain,
primarily also in Desktop GIS.

Many desktop GIS build on top of OGR (e.g. the one we use: QGIS). They
won't bother with curves until their underlying base infrastructure
supports curves.

I know it is a probably a huge effort to include curve support in OGR and
won't happen tomorrow ... However, since more and more data formats and
applications now start to support curves, it would make sense that OGR
would support them as well, esp. since it is at the technical foundation
of so many other tools.

I know it should be financially supported by the users, so I wonder if we
could start a project like the WKTRaster project in Postgis [1], where the
necessary work packages for curve support are laid out, as well as
potential programmers and sponsors. People/organizations can assign
themselves as sponsors for certain parts of the whole work then.

The whole thing of course also concerns GEOS and Postgis.

Andreas

[1] http://trac.osgeo.org/postgis/wiki/WKTRaster/PlanningAndFunding


On Thu, June 18, 2009 11:49 pm, Mateusz Loskot wrote:
> Andreas Neumann wrote:
>> sdf (used for Mapguide)
>
> If you use MapGuide, you also use FDO.
> FDO does support curves, so you can forget about OGR and just use FDO.
>
> Cheers,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> Charter Member of OSGeo, http://osgeo.org
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Curve support in OGR

[Andreas Neumann]

Hi all,

I am sure this topic is coming up once in a while. I wonder what the 
take is on curve support in the OGR feature model.


Most formats we use now support curves, but our favorite translation 
engine does not. For curve support I currently have to use FME.


These are the formats/databases we use:

Postgis (Geodata Warehouse)
Oracle Spatial (production system for survey data, linked to Autodesk 
Topobase)

dxf/dwg (file exchange)
SVG (presentation format)
sdf (used for Mapguide)

Most of our survey data contains circular arcs, some datasets also 
contain splines.


I know that curve support in Postgis is somehow limited, but each 
release improves a bit on it and the list of curve-aware operators is 
growing:

http://postgis.refractions.net/documentation/manual-svn/ch08.html#PostGIS_Curved_GeometryFunctions

If OS GIS wants to further penetrate in Switzerland it has to be able to 
deal with curves (at least circular arcs) since they are used all over 
the place.


Of course we are willing to partially help to finance such a development 
(hopefully with some others) if the OGR developers are interested in 
adding curve support and can offer an estimate on how much it would cost 
to implement this (at least on the core and for selected formats).


Thanks,
Andreas


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_merge problems: Negative size passed to PyString_FromStringAndSize

[Andreas Neumann]

Hi Even,

Thank you for your very detailed explanation.

I can now see what the problem is and was able to work around it by
splitting up the larger files first that would exceed the maximum size.

Andreas

On Wed, May 6, 2009 9:36 pm, Even Rouault wrote:
> Le Wednesday 06 May 2009 16:48:06 Andreas Neumann, vous avez écrit :
>> Hi,
>> Filename: a25.tif
>> File Size: 25472x25427x1
>> Pixel Size: 42.431795 x -42.431795
>> UL:(697837651.400476,244274906.596461)
>> LR:(698918474.082743,243195993.344970)
>> Copy 0,0,25472,25427 to 205747,211643,50722,50632.
>
> --> here's the issue. a25.tif is resampled from 25472x25427 to a
> 50722x50632
> raster. But as gdal_merge.py just operates on full buffers, this results
> in
> trying to allocate 50722x50632 pixels = 2 568 156 304 bytes, which is
> above
> the largest 32 bit (signed) integer whose value is 2 147 483 647. So this
> value is interpreated as a negative size by Python...
>
> To make the story short, you didn't do anything wrong. You've just hit a
> known
> limitation of gdal_merge.py.
>
> The issue is that the default pixel size used for the destination merged
> file
> is the pixel size of the first source raster processed, in your case
> 21.309260 x -21.309260 for a01.tif. But a25.tif on which the error occurs
> has
> a pixel size of  42.431795 x -42.431795. So it must be nearly over-sampled
> by
> a factor of 2, so that accounts for his size going from 25472x25427 to a
> 50722x50632.
>
> There are several workarounds :
> - use the -ps flag of gdal_merge.py to increase the pixel size of the
> destination raster. "-ps 30 30" would probably work (provided that you've
> enough memory)
> - or add a preprocessing step that cuts a25.tif into 4 smaller pieces.
> This
> can be done with 4 calls to gdal_translate by using the -srcwin option
> - or use gdalwarp to do the same thing. It has not the limitation of
> gdal_merge.py, but it is known to be much slower.
>
> Patches to improve gdal_merge.py are welcome ;-)
>
>> Traceback (most recent call last):
>>   File "/usr/local/bin/gdal_merge.py", line 427, in 
>> fi.copy_into( t_fh, band, band, nodata )
>>   File "/usr/local/bin/gdal_merge.py", line 227, in copy_into
>> nodata_arg )
>>   File "/usr/local/bin/gdal_merge.py", line 47, in raster_copy
>> nodata )
>>   File "/usr/local/bin/gdal_merge.py", line 83, in
>> raster_copy_with_nodata
>> t_xsize, t_ysize )
>>   File
>> "/usr/lib/python2.5/site-packages/GDAL-1.6.0-py2.5-linux-x86_64.egg/osgeo/g
>>dal.py", line 835, in ReadAsArray
>> buf_xsize, buf_ysize, buf_obj )
>>   File
>> "/usr/lib/python2.5/site-packages/GDAL-1.6.0-py2.5-linux-x86_64.egg/osgeo/g
>>dal_array.py", line 133, in BandReadAsArray
>> buf_xsize, buf_ysize, datatype )
>>   File
>> "/usr/lib/python2.5/site-packages/GDAL-1.6.0-py2.5-linux-x86_64.egg/osgeo/g
>>dal.py", line 760, in ReadRaster
>> return _gdal.Band_ReadRaster(*args, **kwargs)
>> SystemError: Negative size passed to PyString_FromStringAndSize
>> ---
>>
>> Is this a problem with my data, georeferencing or projection or is it a
>> problem in gdal_merge?
>>
>> Thanks for any idea what might be wrong in this case!
>>
>> Andreas
>
>
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdal_merge problems: Negative size passed to PyString_FromStringAndSize

[Andreas Neumann]

88963,23803,29890.

Filename: a21.tif
File Size: 24408x16665x1
Pixel Size: 21.297079 x -21.297079
UL:(697492717.281869,244504989.972687)  
LR:(698012536.394027,244150074.145740)
Copy 0,0,24408,16665 to 189560,200846,24395,16656.

Filename: a22.tif
File Size: 23616x16571x1
Pixel Size: 21.264780 x -21.264780
UL:(697417036.817021,244399776.304582)  
LR:(697919225.865369,244047397.632488)
Copy 0,0,23616,16571 to 186009,205783,23567,16537.

Filename: a23.tif
File Size: 25624x29314x1
Pixel Size: 21.223764 x -21.223764
UL:(697662502.145363,244415030.489332)  
LR:(698206339.866522,243792877.080104)
Copy 0,0,25624,29314 to 197528,205067,25522,29197.

Filename: a25.tif
File Size: 25472x25427x1
Pixel Size: 42.431795 x -42.431795
UL:(697837651.400476,244274906.596461)  
LR:(698918474.082743,243195993.344970)
Copy 0,0,25472,25427 to 205747,211643,50722,50632.
Traceback (most recent call last):
  File "/usr/local/bin/gdal_merge.py", line 427, in 
fi.copy_into( t_fh, band, band, nodata )
  File "/usr/local/bin/gdal_merge.py", line 227, in copy_into
nodata_arg )
  File "/usr/local/bin/gdal_merge.py", line 47, in raster_copy
nodata )
  File "/usr/local/bin/gdal_merge.py", line 83, in raster_copy_with_nodata
t_xsize, t_ysize )
  File
"/usr/lib/python2.5/site-packages/GDAL-1.6.0-py2.5-linux-x86_64.egg/osgeo/gdal.py",
line 835, in ReadAsArray
buf_xsize, buf_ysize, buf_obj )
  File
"/usr/lib/python2.5/site-packages/GDAL-1.6.0-py2.5-linux-x86_64.egg/osgeo/gdal_array.py",
line 133, in BandReadAsArray
buf_xsize, buf_ysize, datatype )
  File
"/usr/lib/python2.5/site-packages/GDAL-1.6.0-py2.5-linux-x86_64.egg/osgeo/gdal.py",
line 760, in ReadRaster
return _gdal.Band_ReadRaster(*args, **kwargs)
SystemError: Negative size passed to PyString_FromStringAndSize
---

Is this a problem with my data, georeferencing or projection or is it a
problem in gdal_merge?

Thanks for any idea what might be wrong in this case!

Andreas

-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Converting big Intergraph cit files

[Andreas Neumann]

Thanks, Lucena.

This seems to the issue. I am using 1.6.0 (not trunk). Meanwhile I was
able to solve the issue with nconvert (xnview) as a workaround.

Thanks,
Andreas

On Wed, May 6, 2009 4:01 pm, Lucena, Ivan wrote:
> Andreas,
>
> If that issue is related to http://trac.osgeo.org/gdal/ticket/1959 check
> the version you are using.
>
> Ivan
>
>
>>  ---Original Message---
>>  From: Andreas Neumann 
>>  Subject: [gdal-dev] Converting big Intergraph cit files
>>  Sent: May 06 '09 01:58
>>
>>  Hi all,
>>
>>  I am trying to convert Intergraph cit files. While it works perfectly
>> fine
>>  for medium-size cit files it fails for bigger cit files. I get the
>>  following error message:
>>
>>  u...@server:/home/www/mapserverdata/lk_alt$ gdal_translate -of GTiff
>>  -a_srs EPSG:21781 -a_nodata 0 -co 'TFW=YES' -co 'COMPRESS=PACKBITS' -co
>>  'NBITS=1'
>> /home/an/server/geonis/UsterAV01/LK_Raster/B_Kirchuster/b04.cit
>>  b04.tif
>>  Input file size is 46368, 46368
>>  0ERROR 6: Too big block : 46368 * 46368
>>  ERROR 6: Too big block : 46368 * 46368
>>  ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0
>>
>>  Files with sizes below 3 x 3 pixels convert fine.
>>
>>  I know, those eccentric Intergraph raster files are going to die/fade
>>  away, anyway - that's why I want to convert them to something more
>>  mainstream ...
>>
>>  Is there any compile-time switch or a commandline option I could use to
>>  work around the problem with bigger cit files?
>>
>>  http://www.gdal.org/frmt_intergraphraster.html doesn't list any size
>>  limitations with the intergraph drivers.
>>
>>  Thanks,
>>  Andreas
>>
>>  --
>>  Andreas Neumann
>>  http://www.carto.net/neumann/
>>  http://www.svgopen.org/
>>
>>  ___
>>  gdal-dev mailing list
>>  gdal-dev@lists.osgeo.org
>>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Converting big Intergraph cit files

[Andreas Neumann]

Hi all,

I am trying to convert Intergraph cit files. While it works perfectly fine
for medium-size cit files it fails for bigger cit files. I get the
following error message:

u...@server:/home/www/mapserverdata/lk_alt$ gdal_translate -of GTiff
-a_srs EPSG:21781 -a_nodata 0 -co 'TFW=YES' -co 'COMPRESS=PACKBITS' -co
'NBITS=1' /home/an/server/geonis/UsterAV01/LK_Raster/B_Kirchuster/b04.cit
b04.tif
Input file size is 46368, 46368
0ERROR 6: Too big block : 46368 * 46368
ERROR 6: Too big block : 46368 * 46368
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0

Files with sizes below 3 x 3 pixels convert fine.

I know, those eccentric Intergraph raster files are going to die/fade
away, anyway - that's why I want to convert them to something more
mainstream ...

Is there any compile-time switch or a commandline option I could use to
work around the problem with bigger cit files?

http://www.gdal.org/frmt_intergraphraster.html doesn't list any size
limitations with the intergraph drivers.

Thanks,
Andreas

-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Overwriting Georeferencing Information of a GeoTIFF file

[Andreas Neumann]

Thanks Nikos and Benoît!

The solution with the BASELINE profile seems to work perfect. Haven't
thought about that!

Thank you for your quick help!

Andreas


On Tue, May 5, 2009 2:31 pm, Benoît Andrieu wrote:
> Hi,
>
> Some times ago, I tried to update the georeferencing information by code
> but it didn't seem to work.
> My solution was to first destroy the informations by using gdal_translate
> with -co PROFILE=BASELINE
> Then to use the new Tiff with a prj file to have a GTiff
>
> PROFILE=[GDALGeoTIFF/GeoTIFF/BASELINE]: Control what non-baseline tags are
> emitted by GDAL.
>
> * With GDALGeoTIFF (the default) various GDAL custom tags may be
> written.
> * With GeoTIFF only GeoTIFF tags will be added to the baseline.
> * With BASELINE no GDAL or GeoTIFF tags will be written. BASELINE is
> occationally useful when writing files to be read by
> applications intolerant of unrecognised tags.
>
> There could be some better way...
>
> Regards,
>
> Benoît Andrieu
> b...@ixsea.com
> benoit.andr...@gmail.com
>
> - Original Message -
> From: "Andreas Neumann" 
> To: 
> Sent: Tuesday, May 05, 2009 1:53 PM
> Subject: [gdal-dev] Overwriting Georeferencing Information of a GeoTIFF
> file
>
>
>> Hi GDAL users/developers,
>>
>> Is it possible to overwrite georeferencing information of an existing
>> geotiff file? For some reasons, some of the files I received have
>> georeferencing information in Millimeters instead of Meters. All of my
>> data uses meters as units.
>>
>> I thought that maybe it is possible to create a tfw file and modify the
>> tfw file, but since the tiff file also has the original georeferencing
>> information in millimeters, the internal georeferencing still takes
>> precedence over the external tfw file. Is there some way to force gdal
>> to
>> prefer the tfw file?
>>
>> If not - what else could I do? Write different projection files?
>>
>> Actually, I don't want to modify the rasters at all, just the
>> georeferencing information.
>>
>> Thanks for any hints,
>> Andreas
>>
>>
>> --
>> Andreas Neumann
>> http://www.carto.net/neumann/
>> http://www.svgopen.org/
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Overwriting Georeferencing Information of a GeoTIFF file

[Andreas Neumann]

Hi GDAL users/developers,

Is it possible to overwrite georeferencing information of an existing
geotiff file? For some reasons, some of the files I received have
georeferencing information in Millimeters instead of Meters. All of my
data uses meters as units.

I thought that maybe it is possible to create a tfw file and modify the
tfw file, but since the tiff file also has the original georeferencing
information in millimeters, the internal georeferencing still takes
precedence over the external tfw file. Is there some way to force gdal to
prefer the tfw file?

If not - what else could I do? Write different projection files?

Actually, I don't want to modify the rasters at all, just the
georeferencing information.

Thanks for any hints,
Andreas


-- 
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [Gdal-dev] KML with descriptions from Postgis Views via ogr2ogr

[Andreas Neumann]

Hi Georges,

I usually generate my KML files with a scripting language like PHP or
Perl. It gives you more fine-grained control over the structure and
content of the KML as opposed to "automatic" conversions like ogr2ogr or
FME.

It might be useful to post your KML somewhere if you want to have comments.

The KML tutorials at Google might be useful to get more insight on what
might be wrong with your KML:

http://code.google.com/apis/kml/documentation/kml_tut.html
also contains a KML reference.

If you want I can send you PHP examples how I generate polygons to KML
from Postgis. It is actually quite simple, since Postgis already offers
the AsKML() command for converting the geometry.

Andreas

>
> I'm really impressed by the command-line functionality of ogr2ogr, since
> I've
> found until now no suitable gui to use it under Windows.
>
> Actually I try to create KML-files from Postgressql/Postgis-data with
> ogr2ogr, which works fine. I encountered only two problems, that I
> couldn't
> solve until now. Maybe there is someone that can help me.
>
> My command looks like this:
> ogr2ogr -f KML c:/parzellen.kml PG:"host=localhost port=5432 dbname=test
> user=postgres password=" -sql "select ka_nr, ka_sect as Sektion,
> ka_flur
> as Flur, ka_akte as Kaufakte, kart_dat as Kartierdatum, kart_pers as
> Kartierer, pacht as Pächter, transform(the_geom,4326) from view_kataster"
> -dsco NameField=kadaster_nr -dsco
> DescriptionField=Sektion,Flur,Kaufakte,Kartierdatum,Kartierer,Pächter
>
> My main problem is, that the kml-file is created, but doesn't display at
> the
> right place in Google Earth. When opening the file in GE first GE zooms
> close to the place, where the polygons should be. When I click in GE on
> the
> imported layer, all the polygons are there, but they are displayed as
> point
> marker??? When I click them, I get a balloon, with only a part of the
> informations I wanted to be displayed. The main problem is, that the
> balloons sit 'lost in space', meens outside the earth somewhere in space
> ??
> When i hover the balloons with the mouse, the displayed lat and lon, and
> hight values are OK.
> I've tried to indicate the source and the target projection with -s_srs
> "EPSG:2169" or -t_srs "EPSG:4326", but without other results.
>
> The underlying table works fine, so maybe there is a problem with using
> views in ogr2ogr???
>
> The other problem is, that the kml-file only contains the NameField and
> the
> 3 first DescriptionFields (Sektion,Flur,Kaufakte), the rest is ignored.
> Are
> there any restrictions I've ignored?
>
> Maybe there is someone, who could give me an a tip or an answer to my
> questions?
>
>
> --
> View this message in context:
> http://n2.nabble.com/KML-with-descriptions-from-Postgis-Views-via-ogr2ogr-tp2255911p2255911.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
>


-- 
Andreas Neumann
Böschacherstrasse 6, CH-8624 Grüt/Gossau, Switzerland
Email: a.neum...@carto.net, Web:
* http://www.carto.net/ (Carto and SVG resources)
* http://www.carto.net/neumann/ (personal page)
* http://www.svgopen.org/ (SVG Open Conference)
* http://www.geofoto.ch/ (Georeferenced Photos of Switzerland)

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Update on OGR DXF Driver?

[Andreas Neumann]

we have a meeting next week (January 28) and I will discuss the issue 
there again. I hope that we find someone who will finance it. After all, 
Franks offer seems to be affordable.


I will report back in a few days.

Andreas

Frank Warmerdam wrote:

Shaun & Melissa Busler wrote:

I was wondering if any progress has been made on the development of an
OGR DXF Driver.  I saw some discussion in the archives back in 10/2008
but have not seen any postings since.


Shaun,

This effort appears to be stalled currently (to the best of my 
knowledge).


Best regards,



--
--
Andreas Neumann
Böschacherstrasse 6
CH-8624 Grüt (Gossau ZH)
Switzerland
Phone: ++41-44-2736668
Email: a.neum...@carto.net

Web: http://www.carto.net/neumann/
SVG Examples: http://www.carto.net/papers/svg/samples/
SVG.Open: http://www.svgopen.org/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] resampling a raster data set on the commandline

[Andreas Neumann]

Hi all,

I need to resample raster files on the command line.

First I thought that resampling would be an option of gdal_translate, but
it seems like it isn't implemented and there is a patch pending:
http://trac.osgeo.org/gdal/ticket/1724 - but this patch is against an old
version.

gdal_warp allows to specify the resampling method and resolution change
when reprojecting, but I don't want to reproject my data, I just want
resampling. Is gdal_warp the tool to use for resampling by specifying the
same input and output projection?

Thanks,
Andreas

-- 
Andreas Neumann
Böschacherstrasse 6, CH-8624 Grüt/Gossau, Switzerland
Email: [EMAIL PROTECTED], Web:
* http://www.carto.net/ (Carto and SVG resources)
* http://www.carto.net/neumann/ (personal page)
* http://www.svgopen.org/ (SVG Open Conference)
* http://www.geofoto.ch/ (Georeferenced Photos of Switzerland)

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] mod_python problems, bigtiff

[Andreas Neumann]

Hi,

I have a very simple python script that queries some metadata from raster
images. The script works fine on the console and in a web application with
mod_python. I am still rather new to python and mod_python.

A problem arises when I query meta information of big tiff files, larger
than 4GB. In this case the script works fine when I run it from the
command line, but fails when I run it from the server with mod_python.

Here is the error message from the apache error-log:

--

[Thu Oct 16 17:22:00 2008] [notice] mod_python (pid=32194,
interpreter='srv139.stadt-uster.ch'): Importing module
'/home/www/www/datenextraktion_dev/extract_meta.py'
ERROR 1:
/home/www/mapserverdata/orthofotos/release_2008/orthofoto_2008.tif:This is
a BigTIFF file.  This format not supported
by this version of libtiff.
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] mod_python
(pid=32194, interpreter='srv139.stadt-uster.ch', phase='PythonHandler',
handler='mod_python.publisher'): Application error
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] ServerName:
'srv139.stadt-uster.ch'
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] DocumentRoot:
'/home/www/www/'
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] URI:
'/datenextraktion_dev/extract_meta.py/raster'
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] Location: None
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] Directory: '/'
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] Filename:
'/home/www/www/datenextraktion_dev/extract_meta.py'
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] PathInfo: '/raster'
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] Traceback (most
recent call last):
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101]   File
"/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1537, in
HandlerDispatch\ndefault=default_handler, arg=req,
silent=hlist.silent)
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101]   File
"/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1229, in
_process_target\nresult = _execute_target(config, req, object, arg)
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101]   File
"/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1128, in
_execute_target\nresult = object(arg)
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101]   File
"/usr/lib/python2.5/site-packages/mod_python/publisher.py", line 213, in
handler\npublished = publish_object(req, object)
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101]   File
"/usr/lib/python2.5/site-packages/mod_python/publisher.py", line 425, in
publish_object\nreturn publish_object(req,util.apply_fs_data(object,
req.form, req=req))
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101]   File
"/usr/lib/python2.5/site-packages/mod_python/util.py", line 554, in
apply_fs_data\nreturn object(**args)
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101]   File
"/home/www/www/datenextraktion_dev/extract_meta.py", line 18, in raster\n 
 
req.write('\\t'+dataset.GetDriver().ShortName+'/'+dataset.GetDriver().LongName+'\\n')
[Thu Oct 16 17:22:00 2008] [error] [client 192.168.1.101] AttributeError:
'NoneType' object has no attribute 'GetDriver'



My guess was that mod_python picks up a different version of gdal.py and
the osgeo package but I can only find one installation of gdal.py on the
server. I also explicitly set the paths to the packages/modules in the
apache config:

PythonOption mod_python.importer.path
"['/usr/local/lib/python2.5/site-packages','/usr/lib/python2.5/site-packages']"

Are there any other ideas why my script works in the command line and not
in the web environment?

Thanks,
Andreas

-- 
Andreas Neumann
Böschacherstrasse 6, CH-8624 Grüt/Gossau, Switzerland
Email: [EMAIL PROTECTED], Web:
* http://www.carto.net/ (Carto and SVG resources)
* http://www.carto.net/neumann/ (personal page)
* http://www.svgopen.org/ (SVG Open Conference)
* http://www.geofoto.ch/ (Georeferenced Photos of Switzerland)

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Supporting ECW as GDAL plugin.

[Andreas Neumann]

Hi Daniele,

You need to install the ecw libraries. For Unix/Linux/MacOSX you need to
compile from source. You can get the libraries from
http://www.ermapper.com/ProductView.aspx?t=131 - after installing the
libraries you need to tell gdal where to find them and re-compile gdal.

I don't know what the exact licence terms are. It is a commercial product
and in the past there was a limitation that files with the public version
could not grow past 500MB in size, which is pretty severe limitation.

The binary versions fwtools (http://fwtools.maptools.org/) should contain
ecw support, but I don't know if the limitation exists or not.

Because of this limitation I am currently not using ecw.

Maybe there was a change in the licence terms, however. I am not totally
up to date.

See also http://www.gdal.org/frmt_ecw.html

> Hi list,
> I would like to get some information about how to support ECW as a GDAL's
> plugin.
> Andrea Aime, back from the FOSS4G, have proposed to improve the support to
> ECW format offered by our ImageIO-Ext project,
> by leveraging on GDAL plugin mechanism.
> Which steps are involved to support ECW Driver as a plugin? (on both
> Windows/Linux).
> Should I also tweak the java bindings generation step to handle this?
>
> Any information/suggestion/link would be greatly appreciated. (I have
> already taken a look at ticket 2385)
>
> Thank you very much.
> Regards,
> Daniele
>
> --
> ---
> Eng. Daniele Romagnoli
> Software Engineer
>
> GeoSolutions S.A.S.
> Via Carignoni 51
> 55041 Camaiore (LU)
> Italy
>
> phone: +39 0584983027
> fax: +39 0584983027
> mob:   +39 328 0559267
>
>
> http://www.geo-solutions.it
>
> ---
> _______
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
Andreas Neumann
Böschacherstrasse 6, CH-8624 Grüt/Gossau, Switzerland
Email: [EMAIL PROTECTED], Web:
* http://www.carto.net/ (Carto and SVG resources)
* http://www.carto.net/neumann/ (personal page)
* http://www.svgopen.org/ (SVG Open Conference)
* http://www.geofoto.ch/ (Georeferenced Photos of Switzerland)

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev