nastra closed issue #10260: Geospatial Support
URL: https://github.com/apache/iceberg/issues/10260
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issue
nastra commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2690889394
Closing this as this has been added to the spec via
https://github.com/apache/iceberg/pull/10981
--
This is an automated message from the Apache Git Service.
To respond to the mes
jaakla commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2541099197
IMHO the concept of SPATIAL_REF_SYS, (and the other geo metadata tables) is
a bit legacy from the times when (1) storage was really expensive and (2)
databases did not have proper w
dmeaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2411589147
Would it be worth it to add internal mechanisms to Iceberg to treat
geospatial metadata and coordinate reference system data similar to manifest
lists and manifest files? So, an Ice
jiayuasu commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2262098914
Thank you all for the great discussion. We will focus on the Parquet
geometry proposal for now, then come back to the Iceberg one.
As I already commented in the Parquet Geom
cholmes commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2260700912
> I agree that reducing the amount of options is desired. However, the
argument in favour of PROJJSON is biased. It assumes that there is only two
options: having PROJ, or having n
desruisseaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2258925813
> Yes, except that every language can easily parse JSON
Well, in Java we need an external library for parsing JSON. But we are going
in circles: JSON is easier to parse
kylebarron commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2258914313
> The argument works in both ways
Yes, except that every language can easily parse JSON; parsing WKT (even to
just check for specific fields) is a tall order to do correct
kylebarron commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2258835078
> Those libraries support WKT, not PROJJSON
The conversion between PROJJSON and WKT 2 is (relatively) simple
https://github.com/rouault/projjson_to_wkt
--
This is an au
desruisseaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2258748883
I agree that reducing the amount of options is desired. However, the
argument in favour of PROJJSON is biased. It assumes that there is only two
options: having PROJ, or havin
kylebarron commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2258691857
> Pushing 5+ different options that all have slightly different trade-offs
onto the responsibility of the authors of readers/writers isn't going to lead
to a great outcome
cholmes commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2258674234
> One can put WKT2 CRS, SRID, PROJJSON, CRSJSON in this string value. It is
the reader / writer's responsibility to figure out what the string is. Does
this make sense?
I d
desruisseaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2255338418
> In addition, how does one can tell the string is in a certain CRS format
(maybe by reading the first few characters, or try catch exception handling )?
For WKT 1 (if a
desruisseaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2255315231
Citing only the libraries that I know (more may be available):
* C/C++
* PROJ can parse all the above.
* [ESRI prototype](https://github.com/Esri/ogc-crs-wkt-pa
jiayuasu commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2254662914
@dmeaux Great. Can you also explain that what are the OSS libraries
available to parse these CRS formats? Ideally, we are looking for options in
both C, Java, and Python.
I
desruisseaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2254563957
A CRS as a string field is fine. I suggest to limit the allowed formats to
the following:
* WKT 2 as defined by ISO 19162
* SRID in the following forms:
* HTTP U
jiayuasu commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2253467257
@desruisseaux Thanks for the great suggestion.
The status of this PR is to wait until the Parquet format accepts the
geometry type (mostly by absorbing GeoParquet into the P
desruisseaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2249997624
To summarize:
Next to the _"Coordinate Reference System, ie mapping of how coordinates
refer to precise locations on earth"_ sentences, it may be worth to said that
OGC
dmeaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2245899622
@szehon-ho, you should see comments from @desruisseaux, our CRS and metadata
expert (among many other things). For your background, he sits on several OGC
standards committees and i
szehon-ho commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2245797212
Hi @dmeaux thanks for the note! Look forward if you have comments on the
proposal.
Currently I believe this is seeing if the necessary support in
https://github.com/apa
dmeaux commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2244515914
Hi,
I work at [Geomatys](https://geomatys.com/). We are interested in
contributing to this effort, including bringing our 20+ years of experience and
expertise from developin
jiayuasu commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2089326700
Looking forward to the feedback from Iceberg community!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use th
szehon-ho commented on issue #10260:
URL: https://github.com/apache/iceberg/issues/10260#issuecomment-2089324826
Note: thanks to @jiayuasu and @Kontinuation from Wherobots for invaluable
domain specific advice and POC support from Havasu Iceberg-fork and Geolake,
and also @badbye and other
szehon-ho opened a new issue, #10260:
URL: https://github.com/apache/iceberg/issues/10260
### Proposed Change
(This is an abridged version of the proposal document)
Big data open source projects have been leveraged for storage and analysis
of geospatial data for a long time, an
24 matches
Mail list logo
