Re: [gdal-dev] Compilation error gdal / git
Hi, Although a bit annoying, you can probably just ignore the warnings emitted by ./autogen.sh with autoconf 2.71, and run ./configure right behind, without trying autoupdate I've a clean up in https://github.com/OSGeo/gdal/pull/4626 that results in ./autogen.sh not emitting warning with autoconf 2.69 or 2.71. That's a bit risky material though, so this will likely only go to master / 3.4dev, and not in 3.3 branch Even Le 07/10/2021 à 09:47, APM a écrit : Dear List, if I try to compile gdal, I got an error message, see below in this email. I use Debian testing and git: git clone https://github.com/OSGeo/gdal.git cd gdal git checkout master cd gdal ./autogen.sh configure.ac:6172: warning: AC_OUTPUT should be used without arguments. configure.ac:6172: You should run autoupdate. autoupdate configure.ac:212: warning: AC_PROG_CC_C99 is obsolete; use AC_PROG_CC configure.ac:289: warning: The preprocessor macro `STDC_HEADERS' is obsolete. Except in unusual embedded environments, you can safely include all ISO C90 headers unconditionally. ./configure --prefix=/home/user/apps/gdal/ make -j4 Error: /src/gdal/gdal$ ./autogen.sh + aclocal -I ./m4 configure.ac:218: error: AC_REQUIRE(): cannot be used outside of an AC_DEFUN'd macro configure.ac:218: the top level autom4te: error: /usr/bin/m4 failed with exit status: 1 aclocal: error: autom4te failed with exit status: 1 + autoconf configure.ac:218: error: AC_REQUIRE(): cannot be used outside of an AC_DEFUN'd macro configure.ac:218: the top level autom4te: error: /usr/bin/m4 failed with exit status: 1 I'm not sure if I deal with gdal/git correctly. Maybe you have a tipp? Thank you! Kind regards Piet ___ 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
Re: [gdal-dev] ogr2ogr changes field length
Hi, GDAL has the internal default of 80 characters. GDAL users do not really need other options because fields are automatically expanded when longer strings are appended afterwards but if the shapefile is used in some other software it does happen that it is impossible to insert long strings because there is no room for that in the table. I suppose that you also know that by using the field width of 254 you are also maximizing the size of the .dbf file because it reserves the same fixed amount of disk space for each cell. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: matteo Lähetetty: perjantai 8. lokakuuta 2021 12.29 Vastaanottaja: Rahkonen Jukka (MML) ; Even Rouault ; gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] ogr2ogr changes field length Hi Jukka, works perfectly, thanks! so no default options to impose the field length but it is alterable after Cheers! Matteo ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr changes field length
Hi Jukka, works perfectly, thanks! so no default options to impose the field length but it is alterable after Cheers! Matteo ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr changes field length
Hi,
The best I can suggest to do by using just GDAL utilities is to run this kind
of ogrinfo command for each text field that you have in the shapefile schema:
ogrinfo my_shape.shp -sql "alter table my_shape alter column STRING_1 TYPE
character(254)"
(right, the max length is 254).
-Jukka Rahkonen-
-Alkuperäinen viesti-
Lähettäjä: matteo
Lähetetty: perjantai 8. lokakuuta 2021 11.20
Vastaanottaja: Rahkonen Jukka (MML) ; Even
Rouault ; gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] ogr2ogr changes field length
Hi Jukka,
> The strings fields are created by default with width 80. If there are longer
> strings in the data the width is automatically extended up till 255
> characters that is the maximum that dBase format supports. If strings are
> shorter than 80 charaters it is possible to use RESIZE and shrink the width
> to match the longest string used in that field.
>
> If you need better control on field widths I suppose you must create an empty
> shapefile for ogr2ogr to append by your own code.
>
> # Add a new field.
> field_defn = ogr.FieldDefn('NEWFLD', ogr.OFTString)
> field_defn.SetWidth(12)
>
> Do you have some concrete problem with field widths that you want to resolve?
I'm "dumping" empty tables of a schema to shapefile and actually yes, I need
that the fields with unlimited text set up in PG should be the maximum (so 254)
in the final shapefiles.
All the tables are empty so I guess this is the "problem" I have
Cheers and thanks
Matteo
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr changes field length
Hi Jukka,
The strings fields are created by default with width 80. If there are longer
strings in the data the width is automatically extended up till 255 characters
that is the maximum that dBase format supports. If strings are shorter than 80
charaters it is possible to use RESIZE and shrink the width to match the
longest string used in that field.
If you need better control on field widths I suppose you must create an empty
shapefile for ogr2ogr to append by your own code.
# Add a new field.
field_defn = ogr.FieldDefn('NEWFLD', ogr.OFTString)
field_defn.SetWidth(12)
Do you have some concrete problem with field widths that you want to resolve?
I'm "dumping" empty tables of a schema to shapefile and actually yes, I
need that the fields with unlimited text set up in PG should be the
maximum (so 254) in the final shapefiles.
All the tables are empty so I guess this is the "problem" I have
Cheers and thanks
Matteo
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WFS driver
On 10/7/21 1:46 PM, Rahkonen Jukka (MML) wrote: > Hi, > > If you are asking the same question in gis.stackexchange please wait some > minutes if somebody happens to answer you before sending mail to gdal-dev. Or > vise versa. Crossposting in the long run will not help you to get answers > faster. Well, it helped to get my attention ;-) I'm not so often looking at gis.stackexchange But this USER question (this is not a dev question) I try to answer there now with some examples: https://gis.stackexchange.com/questions/413390/ Hope this helps. Regards, Richard Duivenvoorde ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Compilation error gdal / git
I've had a quick look at what it would take to upgrade for autoconf >= 2.70 compatibility, and it is beyond what I am ready to invest, especially given that part of the code is on the road to be phased out due to the switch to cmake. Your best/only option is to uninstall your apt supplied autoconf and apt install autoconf2.69 regards, On Thu, Oct 7, 2021 at 10:01 AM thomas bonfort wrote: > > we seem to be using deprecated autoconf macros. It should work if you > downgrade autoconf to version 2.69 on your system. I'll look into > fixing our autoconf.ac syntax in a coming PR. > > regards, > Thomas > > On Thu, Oct 7, 2021 at 9:53 AM APM wrote: > > > > Dear List, > > > > > > if I try to compile gdal, I got an error message, see below in this email. > > > > > > I use Debian testing and git: > > > > > > git clone https://github.com/OSGeo/gdal.git > > > > cd gdal > > > > git checkout master > > > > cd gdal > > > > ./autogen.sh > > > > > > configure.ac:6172: warning: AC_OUTPUT should be used without arguments. > > configure.ac:6172: You should run autoupdate. > > > > > > autoupdate > > > > > > configure.ac:212: warning: AC_PROG_CC_C99 is obsolete; use AC_PROG_CC > > > > configure.ac:289: warning: The preprocessor macro `STDC_HEADERS' is > > obsolete. > >Except in unusual embedded environments, you can safely include all > >ISO C90 headers unconditionally. > > > > > > ./configure --prefix=/home/user/apps/gdal/ > > > > > > make -j4 > > > > Error: > > > > /src/gdal/gdal$ ./autogen.sh > > + aclocal -I ./m4 > > configure.ac:218: error: AC_REQUIRE(): cannot be used outside of an > > AC_DEFUN'd macro > > configure.ac:218: the top level > > autom4te: error: /usr/bin/m4 failed with exit status: 1 > > aclocal: error: autom4te failed with exit status: 1 > > + autoconf > > configure.ac:218: error: AC_REQUIRE(): cannot be used outside of an > > AC_DEFUN'd macro > > configure.ac:218: the top level > > autom4te: error: /usr/bin/m4 failed with exit status: 1 > > > > > > I'm not sure if I deal with gdal/git correctly. > > > > > > Maybe you have a tipp? > > > > > > Thank you! > > > > > > Kind regards > > > > > > Piet > > > > > > > > ___ > > 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 changes field length
Hi,
The strings fields are created by default with width 80. If there are longer
strings in the data the width is automatically extended up till 255 characters
that is the maximum that dBase format supports. If strings are shorter than 80
charaters it is possible to use RESIZE and shrink the width to match the
longest string used in that field.
If you need better control on field widths I suppose you must create an empty
shapefile for ogr2ogr to append by your own code.
# Add a new field.
field_defn = ogr.FieldDefn('NEWFLD', ogr.OFTString)
field_defn.SetWidth(12)
Do you have some concrete problem with field widths that you want to resolve?
-Jukka Rahkonen-
-Alkuperäinen viesti-
Lähettäjä: gdal-dev Puolesta matteo
Lähetetty: perjantai 8. lokakuuta 2021 9.11
Vastaanottaja: Even Rouault ;
gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] ogr2ogr changes field length
Hi Even,
> If you add -lco RESIZE=YES fields will be resized to their minimum size.
> See
> https://gdal.org/drivers/vector/shapefile.html#layer-creation-options
yep I see. I also read
* String fields without an assigned width are treated as 80 characters
does it mean that if a field is set as TEXT in PG (without length
definition) the conversion to shapefile is automatically set to 80 and what we
can do is to resize the field length only to have less characters?
Cheers!
Matteo
___
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 changes field length
Hi Even, If you add -lco RESIZE=YES fields will be resized to their minimum size. See https://gdal.org/drivers/vector/shapefile.html#layer-creation-options yep I see. I also read * String fields without an assigned width are treated as 80 characters does it mean that if a field is set as TEXT in PG (without length definition) the conversion to shapefile is automatically set to 80 and what we can do is to resize the field length only to have less characters? Cheers! Matteo ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
