Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 03 19:23
    pvretano commented #641
  • Dec 03 19:22
    pvretano commented #641
  • Dec 03 18:58
    philvarner commented #641
  • Dec 03 18:55
    philvarner commented #641
  • Dec 03 17:30
    pvretano commented #641
  • Dec 03 17:29
    pvretano commented #641
  • Dec 03 17:08
    philvarner commented #641
  • Dec 03 16:34
    philvarner closed #656
  • Dec 03 16:34
    philvarner commented #656
  • Dec 03 16:33
    philvarner opened #657
  • Dec 02 19:07
    pvretano synchronize #641
  • Dec 02 18:43
    pvretano commented #656
  • Dec 02 18:02
    philvarner opened #656
  • Nov 18 01:42
    jerstlouis commented #654
  • Nov 17 21:05
    ghobona commented #654
  • Nov 17 20:22
    pvretano closed #513
  • Nov 17 20:22
    pvretano commented #513
  • Nov 16 12:19
    cportele commented #654
  • Nov 16 09:52
    tinoks commented #654
  • Nov 16 09:52
    tinoks commented #654
Janne Heikkilä
@jampukka
I hope it's not too late to open this issue. My feeling is that these are rarely useful and it feels weird to have them only for stringLiterals but not for numberLiterals. For me this feels more useful color = 0xFF00FF
I propose we remove both bitStringLiteral and hexStringLiteral from cql2-text
Panagiotis (Peter) A. Vretanos
@pvretano
@jampukka not sure where X'414234' came from. I just checked the BNF and I see two dangling productions for bitStringLiteral and hexStringLiteral but no actual definitions for these. I do remember having added these literals way back and the intent was so you could say something like color=0xFF00FF but somewhere along the way the definitions got blown away. We may have decided to remove them -- I don't remember but I created an new issue (#637) to clear things up. I have noted to that you support removing them.
Janne Heikkilä
@jampukka
thanks @pvretano
Janne Heikkilä
@jampukka
Are rings in WKT geometries required to be closed?
Clemens Portele
@cportele
@jampukka - AFAIK: Yes
Janne Heikkilä
@jampukka
Would you return a 400 if they weren't closed in &filter=?
I guess that's safer than trying to close them
Matthias Mohr
@m-mohr
Is someone having/writing a CQL2 text parsing library?
Janne Heikkilä
@jampukka
CQL2: For spatial and temporal geometries existing representations are used:
Spatial geometry:
Text: an OGC Well-Known Text (WKT) literal
JSON: a GeoJSON geometry object,
yet the normative BNF and JSON Schema include envelopeLiteral as well but it doesn't appear in either the linked OGC 06-103r4 or GeoJSON RFC 7946
Janne Heikkilä
@jampukka
OGC 06-103r4 also includes different tags for WKT Geometries with Z, M, ZM dimensions whereas the CQL2 BNF allows 2 or 3 dimensional points/coordinates for everything and doesn't have Z,M, or ZM suffixes for type tags
In addition OGC 06-103r4 allows Polyhedrons and Tins which don't exist in GeoJSON. We should probably rule those out from Part 3 version 1.0 and limit ourselves to the geometry types supported by both OGC WKT and GeoJSON.
Janne Heikkilä
@jampukka
I personally like having envelopeLiteral but it needs to be added as special case to the list of existing representations for geometry
Janne Heikkilä
@jampukka
actually these probably aren't issues for Features Part 3 and but more for CQL2 instead after opengeospatial/ogcapi-features#631
Janne Heikkilä
@jampukka
CQL2 isBetweenPredicate is limited to numericExpressions/numericLiterals. Is this too limiting? Usually it's interchangeable with (min <= value AND value <= max) but here between is far more limited than all basic/standard binary comparison predicates. They allow comparing characterLiterals, numericLiterals, booleanLiterals and also instantLiterals. We should probably also add a note how booleanLiterals are compared to each other, obviously true = true and true <> false but I'm not sure if true is less or greater than false.
Andrea Aime
@aaime
Hey... question about reprojection. What's the take of WFS and/or OGC API Features about having a feature type with multiple geometries in different CRSs? And how should reprojection be handled, given that there can be only one target CRS?
Panagiotis (Peter) A. Vretanos
@pvretano
@aaime multiple geometries per feature each in a different CRS is not restricted. However what you can get back is limited by the API and the desired output format. Without any other indication, all geometric values in the response must be presented in the default CRS. CRS84(h) for OAPIF and the DefaultCRS from the capabilities document for WFS. WFS is a little more flexible since you can have multiple queries in one request each in a different CRS. There are also output format considerations too. For GeoJSON you would need to pick one geometry as the "primary" and encode that as the value of the geometry key. All the geometries could also be encoded into the "properties" section but how that would be done is not specified anywhere.
@aaime GML is a little more flexible since your server can generate an application schema to accomodate all the geometries.
Panagiotis (Peter) A. Vretanos
@pvretano
@aaime if the server implements Part 2 and a CRS is specified then all geometries in the response must be reprojected to the requested CRS in the response. As mentioned above WFS is a little more flexible...but not much.
Janne Heikkilä
@jampukka
Question regarding CQL2, what does "my_geom" IN (spatialLiteral1, spatialLiteral2) or "my_interval" IN (intervalLiteral1, intervalLiteral2) mean? Is it equals, intersects?
Janne Heikkilä
@jampukka
How would you encode WFS <MetadataURL> information in OGC API Features?
Andrea Aime
@aaime
@pvretano thanks a lot for following up! So If I get the WFS side correctly, the extra flexibility means that one can write multiple queries, and reproject each one in a different CRS, producing multiple times the same collection (maybe selecting a different geometry each time).
About "all geometries in the response must be reprojected to the requested CRS in the response"... what if the source has a mix of 2D and 3D geometries? (if I understand correctly, some INSPIRE schemas have that setup). Do we flatten the 3D ones?
Found this in the WFS 2.0 spec: ": A feature with both 2D and 3D geometry properties is requested with srsName set to a 2D CRS; the 2D property is encoded in the requested CRS, and the 3D property is encoded with some 3D CRS identified in the srsName of the geometry." (ah hem... some 3D CRS?)
Clemens Portele
@cportele
@jampukka - IN: It is always equals (" If the value on the left side of the predicate is equal to one or more of the values in the list on the right side of the predicate, the predicate SHALL evaluate to the Boolean value TRUE.")
Janne Heikkilä
@jampukka
so in this case "my_geom" IN (spatialLiteral1, spatialLIteral2) would be shorthand for s_equals("my_geom", spatialLiteral1) OR s_equals("my_geom", spatialLiteral2) and "my_interval" IN (intervalLiteral1, intervalLiteral2) <=> t_equals("my_interval", intervalLiteral1) OR t_equals("my_interval", intervalLiteral2)
Clemens Portele
@cportele
@jampukka - MetadataURL: I would add "describedby" links to the Collection resource.
Yes, that is equivalent
Clemens Portele
@cportele
@aaime - The behaviour for these cases is unspecified in the current parts of OGC API Features. Part 2 only specifies the standard case where all geometries in a collection are in the same CRS (in the backend data provider and in every response).
Janne Heikkilä
@jampukka
Nice to have this cleared. What about services that would like to implement "Advanced Comparison Operators" (LIKE and IS NULL aren't available via Basic CQL2) but don't support "Spatial Operators" and/or "Temporal Operators"? Permission 5 (/per/advanced-comparison-operators/in-predicate) currently allows one to implement "Advanced Comparison Operators" without implementing "Property-Property Comparisons" but there seems to be no Permission that would allow for not supporting spatialLiterals and/or intervalLiterals in inListOperand
Contrasting this to BETWEEN which is currently limited to numericExpressions only it feels a bit weird that IN allows spatialLiterals and intervalLiterals.
Clemens Portele
@cportele
@jampukka - You only have to implement intervals, if you support Temporal Operators, etc. I will create an issue that we should review and clarify dependencies. (From a practical point of view, I am not sure there is much value in using intervals or spatial geometries with IN.)
Janne Heikkilä
@jampukka
Yes, I agree they feel a bit weird to use them with IN.
Janne Heikkilä
@jampukka
About the mixed CRS with 2D and 3D geometries, is this something Features and Geometries JSON SWG has already discussed?
Clemens Portele
@cportele
Only to the extent that the feature can also include a WGS84 (2D or 3D geometry) in "geometry" in addition to the non-GeoJSON geometry in another member that is a solid or in another CRS (for now using "where" as the key). Link
Panagiotis (Peter) A. Vretanos
@pvretano
@aaime with regard to WFS ... yes ... you can write a GetFeatures request with N queries in it. Those queries can have difference srsName and selection clauses in each case ... as long the resulting feature instances are schema valid of course.
NielsCharlier
@NielsCharlier
Just jumping in the conversation (from the geoserver/geotools mailing lists), I found some explanation in the WFS 2.0 OGC specs about srsName and multiple CRSes. section: 7.9.2.4.4 https://docs.opengeospatial.org/is/09-025r2/09-025r2.html#95)
That is where the example Andrea quoted comes from
Nicolai Mogensen
@NicolaiMogensen
I have a question about requests with CRS. In "Part 2: Coordinate Reference Systems by Reference" it is mentioned that CRS uris are of the form: http://www.opengis.net/def/crs/OGC/1.3/CRS84 but in the OGC test suite: https://cite.ogc.org/teamengine/about/ogcapi-features-1.0/1.0/site/ it is mentioned that it can also be in the form of urn:ogc:def:crs:EPSG or http://www.opengis.net/def/crs/EPSG. Should we support both, or just the one. Which documentation is "correct" here?
Janne Heikkilä
@jampukka
I'd argue URL format is more correct. However you cna start preparing for for epsg:4326 (opengeospatial/ogcapi-features#632)
Question about cql2-text, how does one encode/escape single-quote in characterStringLiteral? @pvretano @cportele
Janne Heikkilä
@jampukka
I guess it's by double encoding the quote, e.g. foo'bar => 'foo''bar' but couldn't find it from the spec
Jari Reini
@jreini_gitlab
"foo'bar" in this case is a street name "Tarkk'ampujankatu" in Helsinki :-)
Tom Kralidis
@tomkralidis
hi all: sorry for the off-topic-ish, but does anyone know if there has been any thoughts/work on a profile of OAFeat for geocoding/reverse geocoding?
Panagiotis (Peter) A. Vretanos
@pvretano
@tomkralidis not in features but in the related API OAPIR. OAPIR has an OpenSearch Geo & Time conformance class. One of the query parameters in that conformance class is name. That is supposed to be a place name or address. The idea is that OAPIR would geocode the address OR lookup the placename in a gazetteer to get a location that it could use for a spatial search. You could also combine name with another parameter in that conformance class called radius to performance a proximity search. Does this help?
Tom Kralidis
@tomkralidis
thanks @pvretano. How could this look beyond the OpenSearch conformance class?
Panagiotis (Peter) A. Vretanos
@pvretano
@tomkralidis yes. The main thing the OpenSearch conformance class does is to say "hey, implement this additional set of query parameters on your server to enhance your server's spatial and temporal query capabilities." Since OpenSearch itself is now in an ambiguous states, we could simply remove the reference to OpenSearch and rename the conformance class to something else ... the "enhanced query parameters conformance class" and use it anywhere we like. There is nothing particularly OpenSearch'y about the parameters ... they define pretty basic spatial query capabilities ... just more than simply bbox and datatime. Easy, peasy! ;)
@tomkralidis if you create an issue in OAPIR, I can make the changes there and ... eventually ... this set of parameters could migrate to features or common. This kinda follows what we were talking about early on in the OGC API work. That is to say that we have several "levels" of query capability. At the bottom are bbox & datetime. The middle level are these OpenSearch-base parameters and at the top of the stack is CQL2. Each level add more query capability than the level below it so implementers can pick and choose the level of query capability they need.
Nicolai Mogensen
@NicolaiMogensen
If anyone has experience with teamengine, i would love to know whats wrong with my API. The test: "api Definition Validation" fails with a very long, very repeated number of error messages like so: "java.lang.AssertionError: Landing Page is not valid. Found following validation items: - ERROR: Incorrect JSON value type: Array allow types: Object ..." Is there any way to figure out why this error exists, does it have something to do with conformance classes? I would expect the JSON value type array to be allowed. This makes it so that no other tests in the ApiModel can be tested against. I can supply a test-api here: https://skraafotodistribution-stac-api.k8s-test-121.septima.dk/