nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Creating a SDEF from Geopandas using GeoAccessor gives wrong crs

PaulHallett1305

I am loading from pandas to geopandas to then sue the GeoAccessor to load data in, the code is below:

            df['geometry'] = df['geometry'].apply(wkt.loads)
            gdf = gpd.GeoDataFrame(df, geometry='geometry', crs='epsg:27700')
            sdf = GeoAccessor.from_geodataframe(gdf, True, column_name='SHAPE')
            df_spatial_fc = sdf.spatial.to_featurelayer(
                title=self.layer_name,
                gis=self.gis,
                tags=tags)

However, when I check the crs in the layer, it states it is 3857 (102100). It's leading to anomalies in the display of the data.

Any ideas?

Najděte více příspěvků označených jako

Accepted answers

All comments

jcarlson

Can you call gdf.crs to verify that it's got the right CRS going into the conversion to SEDF?

Also, I don't know what your input data looks like, but could you use gpd.GeoDataFrame.from_file() and skip pandas altogether? I use that method frequently to create a geodataframe directly from WKT or JSON.

PaulHallett1305

Yeah, I checked all that.

Putting gdf.crs() gets epsg:27700 returned, but print out sdf gets this

_prepare_from_string(" ".join(pjargs)) datecreated ... SHAPE 0 2008/07/10 00:00:00 ... {"rings": [[[-0.07844650101657248, 51.46935646... 1 2008/07/10 00:00:00 ... {"rings": [[[-1.7625062007924153, 52.107322561... 2 2008/07/10 00:00:00 ... {"rings": [[[-0.1856100811699591, 51.462464098...

So it's actually converted it to 4326?

PaulHallett1305

So, doing this

            df['geometry'] = df['geometry'].apply(wkt.loads)
            gdf = gpd.GeoDataFrame(df, geometry='geometry', crs="epsg:27700")
            gdf.to_crs(epsg=27700)
            sdf = GeoAccessor.from_geodataframe(gdf, True, column_name='SHAPE')
            print(sdf)

Gets this:

/databricks/python/lib/python3.7/site-packages/pyproj/crs/crs.py:53: FutureWarning: '+init=<authority>:<code>' syntax is deprecated. '<authority>:<code>' is the preferred initialization method. When making the change, be mindful of axis order changes: https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-order-changes-in-proj-6
  return _prepare_from_string(" ".join(pjargs))
            datecreated  ...                                              SHAPE
0   2008/07/10 00:00:00  ...  {"rings": [[[-0.07844650101657248, 51.46935646...
1   2008/07/10 00:00:00  ...  {"rings": [[[-1.7625062007924153, 52.107322561...
2   2008/07/10 00:00:00  ...  {"rings": [[[-0.1856100811699591, 51.462464098...
3   2008/07/10 00:00:00  ...  {"rings": [[[0.14638727113591657, 51.510927694...
4   2008/07/10 00:00:00  ...  {"rings": [[[-0.8200661066061664, 51.874131670...
5   2008/07/10 00:00:00  ...  {"rings": [[[-0.1856100811699591, 51.462464098...
6   2008/07/10 00:00:00  ...  {"rings": [[[-1.0621569871850989, 51.912285240...
7   2008/07/10 00:00:00  ...  {"rings": [[[-0.9991605542955534, 51.633541404...
8   2008/07/10 00:00:00  ...  {"rings": [[[-0.2443546813382341, 51.567339125...
9   2008/07/10 00:00:00  ...  {"rings": [[[-1.0761921118702544, 51.663047862...
10  2014/11/26 00:00:00  ...  {"rings": [[[-1.3225828436443863, 52.148795254...
11  2008/07/10 00:00:00  ...  {"rings": [[[-0.08436864943664825, 51.63673416...
12  2008/07/10 00:00:00  ...  {"rings": [[[-0.4724007834151011, 51.225515245...
13  2008/07/10 00:00:00  ...  {"rings": [[[-0.0983342716542557, 51.574844517...
14  2008/07/10 00:00:00  ...  {"rings": [[[-0.21069183560205398, 51.60838306...
15  2008/07/10 00:00:00  ...  {"rings": [[[-0.05664283387234121, 51.73474899...
16  2008/07/10 00:00:00  ...  {"rings": [[[-0.05450314310272567, 51.63235428...
17  2008/07/10 00:00:00  ...  {"rings": [[[-0.04208239026530489, 51.80219212...
18  2008/07/10 00:00:00  ...  {"rings": [[[-0.2589295080832842, 51.535863752...
19  2008/07/10 00:00:00  ...  {"rings": [[[-0.10171073752288362, 51.62818936...
20  2008/07/10 00:00:00  ...  {"rings": [[[-0.6395494140946187, 51.581788971...

[21 rows x 5 columns]

Checking the PD dataframe, it holds this, as does the geopandas dataframe.

Very confusing.

MULTIPOLYGON (((533564.6773 176238.329500001,533635.9451 176222.1053,533663.1448 176217.004699999,533730.5444 176208.103800001,533730.897 176208.080499999,533767.3441 176205.8026,533789.344 176205.202,533789.7 176205.229,533790.3 176180.7,533779.8088 176175.2092,533767.5896 176169.7785,533754.0126 176162.99,533738.914 176154.424,533729.5742 176147.6028,533717.8075 176139.9092,533706.9459 176132.668199999,533697.4421 176124.522,533684.3177 176115.018200001,533672.0985 176105.061799999,533662.1421 176094.200200001,533655.0498 176087.2009,533643.2104 176073.761600001,533656.3298 176074.7216,533657.2897 176066.562,533632.1 176026.889799999,533627.6 176019.389799999,533618.75 176004.139799999,533615.95 175998.739800001,533614.8132 175998.521500001,533607.8479 175995.591,533607.1 175993.289799999,533593.6 175965.889799999,533577.0 175916.989800001,533572.2 175882.5898,533573.8 175802.3398,533573.5987 175800.4278,533574.2442

geopandas for reference

0   2008/07/10 00:00:00  ...  MULTIPOLYGON (((416362.400 245470.200, 416363....
1   2008/07/10 00:00:00  ...  MULTIPOLYGON (((506767.500 148477.600, 506774....
2   2008/07/10 00:00:00  ...  MULTIPOLYGON (((526140.826 175282.013, 526141....
3   2008/07/10 00:00:00  ...  MULTIPOLYGON (((526140.826 175282.013, 526143....
4   2008/07/10 00:00:00  ...  MULTIPOLYGON (((533564.677 176238.330, 533635....
5   2008/07/10 00:00:00  ...  MULTIPOLYGON (((532665.876 194840.550, 532725....
6   2008/07/10 00:00:00  ...  MULTIPOLYGON (((481327.900 220164.500, 481605....
7   2008/07/10 00:00:00  ...  MULTIPOLYGON (((520853.600 183320.800, 520873....
8   2008/07/10 00:00:00  ...  MULTIPOLYGON (((549044.177 181294.765, 549174....

jcarlson

Strange. Not sure I have any guesses why it's forcing the conversion.

Is it possible to call sdf.project(sr) to get it back to the right CRS after the fact?

PaulHallett1305

I couldn't see it on the object model, but I shall try! So I create an ESRI sr and then pass it in.

We'll see!

jcarlson

I'm actually developing a script right now that uses the gdf → sedf process, and I'm not running into any issues. I have in the past run into serious issues on python envs where GeoPandas and ArcGIS modules are both installed, sometimes requiring me to make a new env from scratch.

Can you try your same code, but leave the inplace parameter set to the default value of False? As you are assigning the output to a new variable, it doesn't make sense for that to be True, as that would convert the gdf object to a SEDF.

PaulHallett1305

Hi Josh,

Thanks for looking at this.

I am creating a SEDF from a Ggeopandas dataframe via the GeoAccessor object so it will be new?

I thought it was false (esssentially I have tried both ways to no avail) - Here's the offending code:

df['geometry'] = df['geometry'].apply(wkt.loads)
gdf = gpd.GeoDataFrame(df, geometry='geometry', crs="epsg:27700")
sdf = GeoAccessor.from_geodataframe(gdf, False, column_name='SHAPE')
# result = project(geometries=df['geometry'], in_sr=4326, out_sr=27700)
df_spatial_fc = sdf.spatial.to_featurelayer(
                title=self.layer_name,
                gis=self.gis,
                tags=tags)

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.