[gdal-dev] About -oo -lco -dsco in docs
Hi, There are implicit rules when you read the OGR/GDAL docs in fact, in particular when you use `ogr2ogr` or `ogrinfo` `-oo =` like "Open Options" `-lco =` for "Layer Creation Option" `-dsco =` for "DataSet Creation Option" So, when you read for instance https://gdal.org/drivers/vector/csv.html, you will see there is a section "Open options" so you will know that you can use `-oo`. Also, you will see a "Layer Creation options" block so again, you will know it mean use `-lco`. It's documented in "ogr2ogr" but you need to know the rule to make the link in your mind when reading the doc. Any idea to clarify the doc about the "tip". An idea could be about adding in drivers docs "Open options" block a sentence like "When using the command line, use the flag `-oo =`" and do the same for "Layer creation options" block "When using the command line, use the flag `-lco =`" Thoughts about the suggestion? Better idea? Not worth? Regards, Thomas Gratier ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Difference between ogr2ogr and Python reprojection
Hello, What about using gdal.VectorTranslate instead? Normally, shorter code and it works like ogr2ogr PS: could be wrong as I didn't tested the exact syntax from osgeo import gdal gdal.VectorTranslate( 'result_command_line.json', 'geojson.json', options='-f GeoJSON -s_srs "+proj=stere +lat_0=90 +lat_ts=60 +lon_0=264 +x_0=0 +y_0=0 +R=6371229 +units=m +no_defs" -t_srs EPSG:4326' ) Regards Thomas Gratier Le mar. 14 mars 2023 à 19:27, Scott a écrit : > While I don't have a direct answer to your question I might ask, why use > 20 lines of python code when 1 line of ogr2ogr gives the correct result? > > > On 3/14/23 11:15, Dion-Degodez,Nicolas (ECCC) wrote: > > _Context_ > > > > We are trying to reproject a GeoJSON polygon to EPSG:4326. > > > > In some cases, depending on whether we use the ogr2ogr command line or > > the equivalent in python, the resulting polygon is different. > > > > In those situations, the command line gives us the appropriate polygon, > > whereas the python code gives us a distorted polygon. > > > > _Question_ > > > > Any idea why there is a difference between the command line and the > > python results? Is there a mistake in our interpretation of the code/how > > we converted it in python? > > > > _Sample GeoJSON_: https://pastebin.com/hUiVVjFv > > <https://pastebin.com/hUiVVjFv> > > > > Proj4: "+proj=stere +lat_0=90 +lat_ts=60 +lon_0=264 +x_0=0 +y_0=0 > > +R=6371229 +units=m +no_defs" > > > > _Command line that works_: ogr2ogr -s_srs "+proj=stere +lat_0=90 > > +lat_ts=60 +lon_0=264 +x_0=0 +y_0=0 +R=6371229 +units=m +no_defs" -t_srs > > EPSG:4326 result_command_line.json geojson.json > > > > Result: https://pasteboard.co/cTpZBRamEYv8.jpg > > <https://pasteboard.co/cTpZBRamEYv8.jpg> > > > > _Python code_ (we would expect the same output as the command line): > > https://pastebin.com/QgWDBL1W <https://pastebin.com/QgWDBL1W> > > > > Result: https://pasteboard.co/8iSv0vbnQlHw.jpg > > <https://pasteboard.co/8iSv0vbnQlHw.jpg> > > > > Thank you! > > > > Nicolas D. > > > > > > ___ > > 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 mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bug/feature: OGR VSICURL does not handle gzip compression
Hi, Use the CURL option available through GDAL e.g https://trac.osgeo.org/gdal/wiki/ConfigOptions#CPL_CURL_GZIP (also documented at https://gdal.org/user/configoptions.html) To illustrate, try the following ogrinfo -so --config CPL_CURL_GZIP YES " https://tie.digitraffic.fi/api/v3/data/traffic-messages/simple?inactiveHours=0=false=TRAFFIC_ANNOUNCEMENT; OGRGeoJSON Regards Thomas Gratier ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Utilisation de Planetary Computer
Hi,
Answer in English although I understand French (after all an english
speaking list here)
You can:
Instead of
vsistr = "/vsicurl?pc_url_signing=yes_collection=sentinel-2-l2a="
red_href = vsistr + planetary_computer.sign(item).assets["B04"].href
cogtif = gdal.Open( red_href )
use
red_href = f"/vsicurl/{planetary_computer.sign(item).assets["B04"].href
}_url_signing=yes_collection=sentinel-2-l2a"
cogtif = gdal.Open( red_href )
Regards
Thomas Gratier
Le mer. 28 sept. 2022 à 10:12, Loïc Lozac'h a écrit :
> Bonjour,
>
> Est-il possible d'utiliser la signature de la librairie python
> Planetary_Computer pour lire des COG depuis le catalogue STAC Microsoft ?
>
> J'ai essayé plusieurs méthode en utilisant /vsicurl/ mais les extended
> filenames associé à la signature ne sont pas reconnu.
>
> Est-il possible de lire ces données à la manière de RasterIO ?
>
> J'utilise gdal version 3.5.2
>
> code python en erreur :
> vsistr = "/vsicurl?pc_url_signing=yes_collection=sentinel-2-l2a="
> red_href = vsistr + planetary_computer.sign(item).assets["B04"].href
> cogtif = gdal.Open( red_href )
>
> response :
>
> Warning 6: Unsupported option: se
> Warning 6: Unsupported option: sp
> Warning 6: Unsupported option: sv
> Warning 6: Unsupported option: sr
> Warning 6: Unsupported option: skoid
> Warning 6: Unsupported option: sktid
> Warning 6: Unsupported option: skt
> Warning 6: Unsupported option: ske
> Warning 6: Unsupported option: sks
> Warning 6: Unsupported option: skv
> Warning 6: Unsupported option: sig
> ERROR 11: HTTP response code: 403
>
> code python ok :
> with fiona.open(shp, "r") as shapefile:
> shapes = [feature["geometry"] for feature in shapefile]
> with rasterio.open(planetary_computer.sign(item).assets["B04"].href ) as
> ds:
> out_image, out_transform = rasterio.mask.mask(ds, shapes, crop=True)
> out_meta = ds.meta
> out_meta.update({"driver": "GTiff",
> "height": out_image.shape[1],
> "width": out_image.shape[2],
> "transform": out_transform})
> with rasterio.open(out, "w", **out_meta) as dest:
> dest.write(out_image)
>
> Merci pour vos réponses
>
> Bien cordialement,
>
> Loïc
> ___
> 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] python - convert CSV of point coordinates to geopackage
Hi, One possible approach using only GDAL https://gist.github.com/ThomasG77/1c76c8fd4f6ee08d9da88dfdb911cfcb It can be also made with higher level abstraction package like geopandas or fiona like mentioned by Alan (also in the same link) Regards Thomas Gratier PS: not sure I've code the fastest solution for 3 approaches Le ven. 17 juin 2022 à 02:48, Alan Snow a écrit : > These references may be helpful: > > https://geopandas.org/en/stable/docs/user_guide/io.html > > > https://geopandas.org/en/stable/docs/reference/api/geopandas.points_from_xy.html > > > On Thu, Jun 16, 2022, 7:14 PM Emily Soth wrote: > >> Hi, >> >> I am trying to create a geopackage from a CSV of point coordinates making >> use of the X_POSSIBLE_NAMES and Y_POSSIBLE_NAMES open options on the CSV >> driver. >> >> I have tried a few things (details are in a gist >> <https://gist.github.com/emlys/60db94cb4017a78219a1aa1dadc0914d>). To >> summarize, I can only set the open options when opening as a gdal.Dataset, >> but then I cannot copy that back into a vector format. >> >> In the source code it looks like open options can be passed to the CSV >> driver's Open function (source >> <https://github.com/OSGeo/gdal/blob/35c07b18316b4b6d238f6d60b82c31e25662ad27/ogr/ogrsf_frmts/csv/ogrcsvdriver.cpp#L142-L167>) >> but I don't know how to use this from the python API since the python >> ogr.Driver.Open function doesn't accept open options unlike gdal.OpenEx. >> >> Thank you! >> - Emily >> ___ >> 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 mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Good morning all and question: Good Python GDAL beginner tutorial?
Hi, You may look on the book side at https://www.manning.com/books/geoprocessing-with-python Regards Thomas Gratier Le lun. 21 févr. 2022 à 16:40, Alan Snow a écrit : > These are also some good resources for GDAL Python: > >- https://carpentries-incubator.github.io/geospatial-python/ >- https://www.earthdatascience.org/tutorials/python/ >- > > https://corteva.github.io/rioxarray/stable/getting_started/getting_started.html >- https://geopandas.org/en/stable/getting_started.html >- https://rasterio.readthedocs.io/en/latest/index.html >- https://fiona.readthedocs.io/en/latest/ > > > > On Mon, Feb 21, 2022 at 8:27 AM Joaquim Manuel Freire Luís > wrote: > >> And if you are open to non-Python alternatives and more upper level, I >> have this small Julia package tailored for satellite data. >> >> https://github.com/GenericMappingTools/RemoteS.jl >> >> Joaquim >> >> -Original Message- >> From: gdal-dev On Behalf Of Stefan >> Gofferje >> Sent: Monday, February 21, 2022 12:15 PM >> To: gdal-dev@lists.osgeo.org >> Subject: Re: [gdal-dev] Good morning all and question: Good Python GDAL >> beginner tutorial? >> >> Hi, >> >> On 2/21/22 12:51, Miguel A. Manso wrote: >> > The cookbook v1 (https://pcjericks.github.io/py-gdalogr-cookbook/) may >> > be a good starting point. >> >> THAT is very cool and almost exactly what I was looking for! Thanks a >> bunch! >> >> > But previos to it you need to install a python developong enviroment. >> > You can trial with miniconda3 software and then creating a new >> > environment and installing GDAL libraries. >> >> I'm on Linux since 1996, but thanks anyways :). >> >> -S >> >> -- >> (o_ Stefan Gofferje| SCLT, MCP, CCSA >> //\ Reg'd Linux User #247167 | VCP #2263 >> V_/_ https://www.gofferje.net | https://www.saakeskus.fi >> >> ___ >> 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 >> > > > -- > Alan Snow > ___ > 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] Adding OSGEO4W and gisinternals docs in install doc?
Hi, I regularly orient third parties to use GDAL utilities and for this intent, point them to install section https://gdal.org/download.html#binaries For Windows, I did not see a user friendly section about how to install it. I want to mention in the doc how to install with OSGEO4W and https://www.gisinternals.com/index.html Opinions? If ok, I will do a PR later on the github repo Regards Thomas Gratier ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Any way to get an autocompletion for ogr/gdal utilities?
Hi Markus, Thanks for your answer. I'm on Linux box rather old e.g Ubuntu 18.04. My shell is bash. I do not find any files for autocompletion within /usr/share/bash-completion/ related to ogr2ogr or any other GDAL binaries or elsewhere. I've also tried to see the behaviour using gdal within conda and no autocompletion available too. I've tried to test autocompletion within a zsh shell in case the issue could have been related to zsh "smartness" but no change. So, what I've done after this various unsuccessful tests is looking at packages version of Ubuntu and I have found the issue. Conclusion: I'm on an Ubuntu box too old No GDAL autocompletion on below versions - Bionic (18.04 LTS) https://packages.ubuntu.com/bionic/amd64/gdal-bin/filelist - Focal (20.04 LTS) https://packages.ubuntu.com/focal/amd64/gdal-bin/filelist GDAL Autocompletion available on - Hirsute (21.04) https://packages.ubuntu.com/hirsute/amd64/gdal-bin/filelist - Impish (21.10) https://packages.ubuntu.com/impish/amd64/gdal-bin/filelist - Jammy (22.04 upcoming LTS) https://packages.ubuntu.com/jammy/amd64/gdal-bin/filelist The remaining issue would be about not getting autocompletion with conda although I tried with the latest version 3.4.1. I think I will open an issue at https://github.com/conda-forge/gdal-feedstock/ Regards Thomas Gratier Le jeu. 3 févr. 2022 à 11:02, Markus Neteler a écrit : > Hi Thomas, > > On Wed, Feb 2, 2022 at 11:59 PM Thomas Gratier > wrote: > > > > Hello, > > > > On Linux, when I type `ogr` in a command line, and on the keyboard type > on "tab" key, I get all binaries starting with `ogr` e.g > > > > > ogr2ogr ogrinfo ogrlineref ogrmerge.py ogrtindex > > > > When using command line like git, I type `git commit --` then use again > the tab key and it returns something like below > > > > > --ahead-behind --date= --include > --no-verify --reedit-message= --status > > > --all --dry-run --interactive --null > --reset-author --template= > > > --amend --edit --long --only > --reuse-message=--untracked-files > > > --author= --file= --message= --patch > --short --verbose > > > --branch--fixup=--no-edit > --porcelain --signoff --verify > > > --cleanup= --gpg-sign --no-post-rewrite --quiet > --squash= > > > > So, I do expect a way to get autocompletion or choice when I do > something like `ogr2ogr -` followed by typing on tab key. > > > > Is there an existing script or a tip I'm not aware? Or do I need to work > to create it to get something similar to git command where there is a > script to add autocompletion? > > AFAIK this requires bash/zsh completion support. > > E.g., for core Git, on my Fedora box it is defined in > > /usr/share/bash-completion/completions/git > > and part of the package: > rpm -qf /usr/share/bash-completion/completions/git > git-core-2.34.1-1.fc35.x86_64 > > Likewise, there is > > /usr/share/bash-completion/completions/ogr2ogr > /usr/share/bash-completion/completions/ogrinfo > /usr/share/bash-completion/completions/ogrlineref > /usr/share/bash-completion/completions/ogrmerge.py > /usr/share/bash-completion/completions/ogrtindex > ... > > Here it works: > ogrinfo -- > --config--format--help-general --locale--pause > --debug --formats --license --optfile --version > > Maybe you package installation is incomplete? > > Best, > Markus > > -- > Markus Neteler, PhD > https://www.mundialis.de - free data with free software > https://grass.osgeo.org > https://courses.neteler.org/blog > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Any way to get an autocompletion for ogr/gdal utilities?
Hello, On Linux, when I type `ogr` in a command line, and on the keyboard type on "tab" key, I get all binaries starting with `ogr` e.g > ogr2ogr ogrinfo ogrlineref ogrmerge.py ogrtindex When using command line like git, I type `git commit --` then use again the tab key and it returns something like below > --ahead-behind --date= --include --no-verify --reedit-message= --status > --all --dry-run --interactive --null --reset-author --template= > --amend --edit --long --only --reuse-message=--untracked-files > --author= --file= --message= --patch --short --verbose > --branch--fixup=--no-edit --porcelain --signoff --verify > --cleanup= --gpg-sign --no-post-rewrite --quiet --squash= So, I do expect a way to get autocompletion or choice when I do something like `ogr2ogr -` followed by typing on tab key. Is there an existing script or a tip I'm not aware? Or do I need to work to create it to get something similar to git command where there is a script to add autocompletion? Regards Thomas Gratier ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Options of gdalwarp not all exposed in the GDAL Python gdal.Warp ?
Hello all,
Due to question at
https://gis.stackexchange.com/questions/398223/how-to-remap-gdal-options-from-string-version-to-a-dictionary-version
I've taken a look at code
When trying to use gdal.Warp from Python, most options are supported but
some seems to be missing
Although an approach with only `gdal.Warp(dest, origin,
options='-overwrite')` can work without code change,
the dict approach like below seems to be simpler from a Python perspective
kwargsoptions = {"overwrite": True} # particular key does not exist, just
for the explanation
gdal.Warp(dest, origin, **kwargsoptions)
Below are the command options I only found in gdalwarp command line but
absent in the WarpOptions (from doc
https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-r)
[-ct string]
[-novshiftgrid]
[-refine_gcps tolerance [minimum_gcps]]
[-ovr level|AUTO|AUTO-n|NONE]
[-srcalpha|-nosrcalpha]
[-q]
[-if format]*
[-overwrite]
[-oo NAME=VALUE]*
[-doo NAME=VALUE]*
-srcalpha is present but not it counterpart -nosrcalpha
In gdal.py code, there are references to resampling option not in the doc
e.g below excerpt
(from
https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/osgeo/gdal.py#L588)
.
elif resampleAlg == GRIORA_Bilinear:
new_options += ['-rb']
elif resampleAlg == GRIORA_Cubic:
new_options += ['-rc']
elif resampleAlg == GRIORA_CubicSpline:
new_options += ['-rcs']
It may to need to be removed if looking at
https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-r
e.g (no -rcs, -rb or -rc options) except maybe for compatibility reason
I will try to make a PR. The main issue is more about naming for each
option.
I also don't know if command line and Python API "unsync" is due to
evolution, to intended API choices or other reasons.
I also only discuss here the gdal.Warp options but I suppose there are
maybe other Python tools ported from RFC 59
https://gdal.org/development/rfc/rfc59_utilities_as_a_library.html that may
have the same "unsync" issue.
Did not look at the moment
Regards
Thomas Gratier
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Installing the latest GDAL version on ubuntu 20.04
Hi, Did you try the following? sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable sudo apt-get update Not sure what you tried Regards Thomas Le jeu. 18 mars 2021 à 17:05, Adzorv1 a écrit : > Thanks for the reply, > > Unfortunately when i try to add ubutugis, i always get the same message: > > Cannot add PPA: 'ppa:~ubuntugis/ubuntu/ubuntugis-unstable'. > ERROR: '~ubuntugis' user or team does not exist. > > i've searched online for solutions such as adding '-E' to the command line, > but it hasn't worked so far > > > > > -- > 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 > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Installing the latest GDAL version on ubuntu 20.04
Hi, First, be sure to "pip3 install -U pip" to get latest pip as got some issues with wheels build because was using outdated pip. In https://pypi.org/project/GDAL/, there is a mention that gdal python bindings have dependencies e.g * libgdal (3.2.2 or greater) and header files (gdal-devel) * numpy (1.0.0 or greater) and header files (numpy-devel) (not explicitly required, but many examples and utilities will not work without it) For 3.1, you will need libgdal 3.1 and headers files The alternative to get a recent gdal without pain is to use conda to install the latest version but I do not know the environment around e.g how you need to link to others software you need to use # With conda already installed conda config --add channels conda-forge conda create --name gdal_latest -y conda activate gdal_latest # get a list of available GDAL versions conda search gdal --channel conda-forge conda install -c conda-forge gdal==3.2.2 -y Regards Thomas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Documenting build requirements (e.g. ODBC)
Hi, In my opinion, although there are not explanations, Travis build files are a good help to sort out building issues dependencies. https://github.com/OSGeo/gdal/tree/master/gdal/ci/travis Mentioning them somewhere could help Regards Thomas Gratier Le dim. 20 oct. 2019 à 22:27, Mateusz Loskot a écrit : > On Sun, 20 Oct 2019 at 19:31, Jeff McKenna > wrote: > > > On lundi 30 septembre 2019 11:21:16 CEST Mateusz Loskot wrote: > > >> > > >> I'm a bit lost where build requirements are supposed > > >> to be documented now. They used to be described > > >> on the Wiki, e.g. https://trac.osgeo.org/gdal/wiki/BuildingOnUnix > > >> or driver-specific ones https://trac.osgeo.org/gdal/wiki/ECW > > > > > > > The wiki worked really well for that, and over the years we compiled > > quite a list of build steps for drivers and platforms > > (https://trac.osgeo.org/gdal/wiki/BuildHints). I'd suggest we continue > > to use the wiki method (meaning now we transition to the Github wiki), > > so we don't have any funnels where someone needs to approve or > > disapprove of a change to the official website or repository. > > I don't have anything against the wiki but a wiki is supposed to be > complementary to existing docs. > > Even suggested to recover the "Compiled by default" column > from the table in the old docs. On reflection, I don't think that > will solve problem I'm calling in this thread - what are the build > requirements of GDAL and features in GDAL. > > IMO, there should be > > https://gdal.org/building/ > https://gdal.org/building/requirements > https://gdal.org/building/unix > https://gdal.org/building/windows > > where https://gdal.org/building/requirements lists common dependencies > similarly to https://pdal.io/development/compilation/dependencies.html > > e.g. it lists ODBC and describes briefly that it is required by drivers A, > B, C, > that on Unix one can use unixODBC or iODBC; that on Windows it comes > with native Windows SDK. > Similarly for libcurl, proj, and any other general purpose dependency of > GDAL. > > > The argument sometimes used against a wiki is that it is not managed, > > but this is exactly why the Buildhints wiki was allowed to thrive. > > Official build procedure with requirements listed is one thing. > Build hints, workarounds and troubleshooting is a different thing. > IMO, the former should be reviewed, curated and up to date > while the latter is a perfect fit for community-written wiki > that can rot... > > > There of course will still be one hurdle, requiring to have a Github > > account, but besides that the wiki should thrive there for years to come. > > Similar hurdle (requirement of an account) applies to OSGeo infrastructure. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > ___ > 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] [mapserver-dev] Wrong .prj file with SHAPEZIP Outputformat
Hello, Just a guess: the Mapserver projection file comes maybe from GEOS and GDAL retrieve the wrong proj (deduce from the mapfile) after (although with your analysis it doesn't seem so) http://mapserver.org/faq.html#where-do-i-find-my-epsg-code Regards Thomas Gratier 2013/5/16 Guillaume Sueur no-re...@neogeo-online.net Hi list(s), Sorry for cross-posting gdal and mapserver dev lists, but I don't know exactly where my problem comes from. When using a SHAPEZIP OUTPUTFORMAT with MapServer, I retrieve a prj file which is not exactly the correct projection definition (for EPSG:3946) : PROJCS[Lambert_Conformal_**Conic,GEOGCS[GCS_GRS 1980(IUGG, 1980),DATUM[D_unknown,**SPHEROID[GRS80,6378137,298.** 257222101]],PRIMEM[Greenwich**,0],UNIT[Degree,0.** 017453292519943295]],**PROJECTION[Lambert_Conformal_** Conic],PARAMETER[standard_**parallel_1,45.25],PARAMETER[** standard_parallel_2,46.75],**PARAMETER[latitude_of_origin** ,46],PARAMETER[central_**meridian,3],PARAMETER[false_** easting,170],PARAMETER[**false_northing,520],UNIT[**Meter,1]] I took a look at the code in mapogroutput.c and noticed it was all driven by OGR. So I did the same extract to a EPSG:3946 shapefile with ogr2ogr. It gives the correct result : PROJCS[RGF93_Lambert_93,**GEOGCS[GCS_RGF93,DATUM[D_** RGF_1993,SPHEROID[GRS_1980,**6378137,298.257222101]],** PRIMEM[Greenwich,0],UNIT[**Degree,0.017453292519943295]]** ,PROJECTION[Lambert_**Conformal_Conic],PARAMETER[** standard_parallel_1,49],**PARAMETER[standard_parallel_** 2,44],PARAMETER[latitude_of_**origin,46.5],PARAMETER[** central_meridian,3],**PARAMETER[false_easting,** 70],PARAMETER[false_**northing,660],UNIT[**Meter,1]] which makes the shapefile's projection understandable by QGIS. So, the question is : where does the prj definition generated by mapserver come from ? Why is it wrong and how to fix this ? Best regards Guillaume __**_ mapserver-dev mailing list mapserver-...@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/mapserver-devhttp://lists.osgeo.org/mailman/listinfo/mapserver-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Apply a style to geojson
Hello, You'd better ask on http://gis.stackexchange.com/ because the list you're using now is dedicated to GDAL developpers not for all purpose GIS questions. Regards ThomasG ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Revealing /vsi*/ for users
Hello Jukka, I agree with you You can also have a look on another gems : Even contribution to python scripts http://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/gdal_ls.py More easy to manipulate than original command line for listing zip content When you do ogrinfo -ro -al -so /vsizip/vsicurl/http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.zip it works because poly.zip contains directly the shp but for example ogrinfo -ro -al -so /vsizip/vsicurl/ http://www.data.rennes-metropole.fr/fileadmin/user_upload/data/data_sig/deplacement/stationnement/stationnement_shp_lamb93.zip will not work if you don't know the remote zip content With python gdal_ls.py -R -l -Rzip http://www.data.rennes-metropole.fr/fileadmin/user_upload/data/data_sig/deplacement/stationnement/stationnement_shp_lamb93.zip you list files and after you can choose the right path to get metadata in the remote zip file e.g ogrinfo -ro -al -so /vsizip/vsicurl/ http://www.data.rennes-metropole.fr/fileadmin/user_upload/data/data_sig/deplacement/stationnement/stationnement_shp_lamb93.zip/stationnement_shp_lamb93/donnees/ Others experiment show me you can also have some problems with remote content because of restrictions on server side. An ogrinfo -ro -al -so /vsizip/vsicurl/ http://www.data.gouv.fr/var/download/6236df97128315a003614bab5201aea3.zip will send you ERROR 1: Range downloading not supported by this server ! ERROR 1: Range downloading not supported by this server ! because vsicurl rely on curl range ability and if not allowed... Regards ThomasG ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] urn and geojson
Hello, I'm playing around with geojson and I haven't found any clue on the doc e.g http://www.gdal.org/ogr/drv_geojson.html about including urn in geojson output. I think it can be useful for sharing geojson and without urn, finding projection isn't really possible. Does I miss the feature? There is a roadmap about this? The form I 'm expecting look like urn:ogc:def:crs:EPSG::26912 (following this discussion http://gis.stackexchange.com/questions/15953/whats-up-with-the-geojson-spec-and-crs-as-a-irmand the official spec http://www.geojson.org/geojson-spec.html#named-crs)http://www.geojson.org/geojson-spec.html#named-crs Regards ThomasG ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem to compile in Lucid with Spatialite 3.0 and gdal 1.9
Hello, Even, concerning the sqlite, it was a mistake from me when writing. The version was the 3.7.10 (and not the 3.3.10) It was done to check if a more recent of sqlite3 could solve my problem. At the end, the choosen solution I've done was the one recommended by Sandro I've reverted sqlite to version 3.6.22 default package I've compiled libspatialite doing ./configure --disable-geocallbacks After, it was smooth for all the other libs e.g spatialite-tools 3.0.0 and gdal 1.9.0 and the related python bindings I now know that amalgation is bad under Linux. Thanks all for your answers Regards ThomasG ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Problem to compile in Lucid with Spatialite 3.0 and gdal 1.9
Hello all, I've done some tests to build gdal 1.9.0 in Ubuntu 10.04 (Lucid) I've build proj 3.3.2, Sqlite 3.3.10, Free XL 1.0.0b, libspatialite amalgation 3.0.0, spatialite-tools 3.0.0 No problem with sqlite alone. # My main problem is when I compile gdal for spatialite support. # I do ./configure --with-geos=yes --with-python --with-spatialite=yes --with-sqlite3=yes --with-curl=/usr/bin/ --with-pg=/usr/lib/postgresql/9.0/bin/pg_config make and I get ... libtool: link: g++ .libs/gdalinfo.o -o .libs/gdalinfo /home/thomas/compile/gdal-1.9.0/.libs/libgdal.so -L/usr/local/lib -L/usr/lib /usr/lib/libodbc.so /usr/lib/libodbcinst.so /usr/lib/libexpat.so -lxerces-c /usr/lib/libNCSEcw.so /usr/lib/libNCSEcwC.so /usr/lib/libNCSCnet.so /usr/lib/libNCSUtil.so /usr/lib/libjasper.so -lnetcdf /usr/lib/libhdf5.so /usr/lib/libmfhdfalt.so /usr/lib/libdfalt.so -logdi /usr/lib/libgif.so /usr/lib/libjpeg.so -lpng -lpq -lz -lrt /usr/local/lib/libspatialite.so -lpthread -ldl /usr/local/lib/libfreexl.so /usr/local/lib/libgeos_c.so /usr/local/lib/libgeos.so /usr/lib/libproj.so -lm /usr/lib/libcurl-gnutls.so gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_bind_int' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_double' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_exec' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_text' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_bind_double' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_bind_blob' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_step' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_get_table' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_open' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_free_table' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_reset' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_vfs_find' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_bytes' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_clear_bindings' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_blob' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_vfs_unregister' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_last_insert_rowid' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_libversion_number' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_name' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_prepare' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_vfs_register' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_int' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_prepare_v2' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_finalize' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_bind_text' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_count' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_close' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_decltype' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_column_type' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_errmsg' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_bind_null' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_free' gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_open_v2' With the ./configure, the return was SQLite support:yes SpatiaLite support:yes Doing ldd /home/thomas/compile/gdal-1.9.0/.libs/libgdal.so|grep lite return libspatialite.so.2 = /usr/local/lib/libspatialite.so.2 (0x012ec000) # The same case without --with-spatialite=yes no problem in the make, but no spatialite support # ./configure --with-geos=yes --with-python --with-sqlite3=yes --with-curl=/usr/bin/ --with-pg=/usr/lib/postgresql/9.0/bin/pg_config make Doing ldd /home/thomas/compile/gdal-1.9.0/.libs/libgdal.so|grep lite return libsqlite3.so.0 = /usr/local/lib/libsqlite3.so.0 (0x0040f000) Question I suppose the list of gdal-1.9.0/.libs/libgdal.so: undefined reference to `sqlite3_* is sent because of the missing libsqlite3.so.0 = /usr/local/lib/libsqlite3.so.0 (0x0040f000) but why the libgdal.so doesn't reference libsqlite3.so too when building using --with-spatialite=yes For information, I've used ldconfig after each build of each lib. Any clue is welcome, maybe I miss something obvious. Thanks ThomasG ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] what does Ring Self-intersection at or near point really mean ?
Hello, I suppose it's similar to Postgis I know better. See this old post http://www.davidgis.fr/blog/index.php?2007/05/11 to understand. It seems to be related to OpenGIS Simple Features for SQLhttp://www.opengeospatial.org/standards/sfs Regards ThomasG GIS specialist ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] What do people think of the MySQL Spatial Extensions?
Hello, For the moment, only need Postgis but there some docs for comparison of spatial functions with mysql, oracle and spatialite. Some years ago, http://cct.cnes.fr/cct05/public/2007/documents/Etude_comp_bases_donnees_spatialisees/rapport_etude_spatiale_final.pdf This year, http://www.rencontres-sig-la-lettre.fr/wp-content/uploads/2010/05/Serveur-Ribot.pdf Be careful !! Everything is in French. Regards ThomasG GIS Specialist ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] (no subject)
Hello, First time I come to this list. I have a problem using FwTools 2.4.7 with VRT and CSV I want to transform french geonames file to PostgreSQL with the geometry build What I do to get this issue ? Creation of a VRT called geonames.vrt containing OGRVRTDataSource OGRVRTLayer name=geonames SrcDataSourcegeonames.csv/SrcDataSource GeometryTypewkbPoint/GeometryType LayerSRSEPSG:4326/LayerSRS GeometryField encoding=PointFromColumns x=latitude y=longitude/ /OGRVRTLayer /OGRVRTDataSource or with attributes OGRVRTDataSource OGRVRTLayer name=geonames SrcDataSourcegeonames.csv/SrcDataSource Field name=latitude type=Real / Field name=longitude type=Real / Field name=geonameid type=Integer / Field name=name type=String width=200 / Field name=asciiname type=String width=200 / Field name=alternatenames type=String width=5000 / Field name=feature class type=String width=10 / Field name=feature code type=String width=10 / Field name=country code type=String width=2 / Field name=cc2 type=String width=60 / Field name=admin1 code type=String width=20 / Field name=admin2 code type=String width=80 / Field name=admin3 code type=String width=20 / Field name=admin4 code type=String width=20 / Field name=population type=Integer / Field name=elevation type=Integer / Field name=gtopo30 type=Integer / Field name=timezone type=String width=100 / Field name=modification date type=Date / GeometryTypewkbPoint/GeometryType LayerSRSEPSG:4326/LayerSRS GeometryField encoding=PointFromColumns x=latitude y=longitude/ /OGRVRTLayer /OGRVRTDataSource Creation of a geonames.csv file with this structure ( file around 3 Mo for all the database on http://raster.analysesig.net/geonames.zip) latitude,longitude,geonameid,name,asciiname,alternatenames,feature class,feature code,country code,cc2,admin1 code,admin2 code,admin3 code,admin4 code,population,elevation,gtopo30,timezone,modification date 45.81667,1.76667,2967103,Peyrat-le-Château,Peyrat-le-Chateau,Peyrat,P,PPL,FR,,B1,87,872,87117,1140,,463,Europe/Paris,2006-04-29 43.16667,-0.91667,2967104,Soule,Soule,La Soule,Soule,Xiberuea,Xiberüa,Zuberoa,L,RGN,FR,,97,64,,,0,,182,Europe/Paris,2006-04-07 45.16667,-0.68333,2967105,Île Boucheau,Ile Boucheau,Ile Bouchaud,Ile du Grand Fagnard,Ile du Grand Fagnarg,Île Bouchaud,Île du Grand Fagnard,Île du Grand Fagnarg,T,ISLX,FR,FR,970,,-,Europe/Paris,1996-03-21 44.81667,6.11667,2967106,Val Godemard,Val Godemard,Val Godemar,T,VAL,FR,FR,B8,05,,,0,,1054,Europe/Paris,1994-01-06 47.5,3.81667,2967107,Domecy-sur-le-Vault,Domecy-sur-le-Vault,Domecy,P,PPL,FR,,A1,89,892,89146,107,,303,Europe/Paris,2006-04-30 45.1,-0.7,2967108,Blaye,Blaye,Blaia,Blaye-et-Sainte-Luce,P,PPLA3,FR,,97,33,331,33058,5277,,-,Europe/Paris,2010-04-19 50.8,2.4,2967109,Zuytpeene,Zuytpeene,,P,PPL,FR,,B4,59,594,59669,483,,30,Europe/Paris,2006-04-30 Finally launching of -- ogr2ogr -f PostgreSQL PG:host=localhost user=username dbname=mydatabase password=my_password geonames.vrt -- It stops in the middle of the import around line 51000 depending of the use of the first or the second VRT example I supposed I miss something but what ? Thanks for any help Regards ThomasG ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
