For GML (~WFS), GDAL automatically tries to determine the data types, but sometimes this goes ~wrong. The easiest option is to disable this by specifying the configuration option GML_FIELDTYPES=ALWAYS_STRING.

Sample script:

import os
from owslib.wfs import WebFeatureService
import geopandas as gpd

wfs = WebFeatureService(url="https://dienste.gdi-sh.de/WFS_SH_ALKIS_VWG_OpenGBD", version="2.0.0", timeout=180)
response = wfs.getfeature(typename="ave:VerwaltungsEinheit")
os.environ["GML_FIELDTYPES"] = "ALWAYS_STRING"
print(gpd.read_file(response).dtypes)

Result:

gml_id          object
identifier      object
oid             object
aktualit        object
art             object
name            object
rs              object
ags             object
uebobjekt       object
ueboname        object
geometry      geometry
dtype: object

Hi @theroggy 👋

Thank you for the explanation! Now I know where the issue is coming from.

But the solution you suggest feels more like creating more issues at other places (e.g. when having integer or floats). I may need to transform more types afterwards (the example above is only one out of almost 100 sources I have in my scripts). So if there are other options it would be really great... :)

Another option that I'm aware of (but never really used) that might be closer to what you are looking for is to use the system of GFS files. It is meant to be able to specify e.g. column types for GML files.

If you open a .gml file, GDAL will create such a file with the default settings, but if they don't please you, you can edit the file to change the settings.

The following script illustrates this. If you run it the first time, GDAL will create a response.gfs file alongside the response.gml file. You can open and edit that file, e.g. by changing the data type of the ags column to String. If you run the script again, the change will be taken in account by read_file...

from pathlib import Path
from owslib.wfs import WebFeatureService
import geopandas as gpd

# Save the WFS response to a .gml file so a .gfs file is saved once 
# it is read with `read_file`.
path = Path("c:/temp/VerwaltungsEinheit.gml")
if not path.exists():

    wfs = WebFeatureService(url="https://dienste.gdi-sh.de/WFS_SH_ALKIS_VWG_OpenGBD", version="2.0.0", timeout=180)
    response = wfs.getfeature(typename="ave:VerwaltungsEinheit")
    with open(path, "wb") as f:
        f.write(response.getbuffer())

    print(gpd.read_file(path).dtypes)

Depending on your exact needs, you can also pass something like GFS_TEMPLATE="VerwaltungsEinheit.gfs" as extra parameter to read_file, and then that configuration file is also used, without having to save the file first.

# Read directly from the WFS response, but specify a .gfs template to specify
# the data types.
from owslib.wfs import WebFeatureService
import geopandas as gpd

wfs = WebFeatureService(url="https://dienste.gdi-sh.de/WFS_SH_ALKIS_VWG_OpenGBD", version="2.0.0", timeout=180)
response = wfs.getfeature(typename="ave:VerwaltungsEinheit")

print(
    gpd.read_file(
        wfs.getfeature(typename="ave:VerwaltungsEinheit"),
        GFS_TEMPLATE="C:/Temp/VerwaltungsEinheit.gfs"
    ).dtypes, 
)

I see. Thank you so much to take your time for this. It is great to know this. But I guess the overhead it creates is larger than the solution of transforming the data back to its correct state in later steps of the pipeline. With several hundred of tables (and increasing) I try to avoid as many intervention that I need to add in my pipelines as possible. I just use a function for now that checks and retransforms the ags columns in my data.

I was planning to do some more follow up on this to explore your first possible solution as well (have it automagically be correct) but - what are the odds - apparently a very similar question was asked on the same day via a "parallel track".

And... that already led to a change in GDAL that should solve your problem: OSGeo/gdal#10902

The change will be backported to GDAL 3.9 as well...

Haha! What a coincidence, truly :) The person who opened the issue is also German. Perhaps because the European High Value Datasets caused a rise of using data from the government now and, thus, many people may encounter this issue now in Germany. Happy it is going to be resolved soon!

WFS users can read the schema with DescribeFeatureType. For example
https://dienste.gdi-sh.de/WFS_SH_ALKIS_VWG_OpenGBD?service=WFS&version=2.0.0&typenames=ave:VerwaltungsEinheit&request=DescribeFeatureType

...
<sequence>
<element name="oid" type="string"/>
<element name="aktualit" type="date"/>
<element name="geometrie" type="gml:MultiSurfacePropertyType"/>
<element name="art" type="ave:Verwaltungseinheit_ArtType"/>
<element name="name" type="string"/>
<element minOccurs="0" name="rs" type="string"/>
<element minOccurs="0" name="ags" type="string"/>
<element minOccurs="0" name="uebobjekt" type="string"/>
<element minOccurs="0" name="ueboname" type="string"/>
</sequence>
...

Resolving the schema from the GML file that is downloaded from WFS into a file may be complicated because the DescribeFeatureType link is not always included in the file, or user may not have internet connection for reading the schema. But if the DescribeFeatureType is available and the contents are correct, but user just does not read it, I would say that user is guilty as well.