Dev environmental exposure #1455
Conversation
…r env_feature extractor
…es with given domain IRI
…tion for route use
…etedata with given IRI
…-feeature endpoint and trajectory endpoint, in case data stored in multiple stacks
… from db directly
…ype and domain name query
…time stamp, as they will be processed in tsclient.py and gps_client
…-formnat column for time series data
…exposure_utilities.py
…sm and ontofhrs ontology (provisional)
…te, improve readability
…oading for point class to aviod warning
…e used in route file
… those two function will be updated once ontoservice is applied to represent opening hours data
…uitable for env data globally
…pe features, suitable for global vector data
…Area type env data whose SRID is not 27700 (27700 is UK only)
| PREFIX gs: <https://www.theworldavatar.com/kg/ontogreenspace/> | ||
| PREFIX geo: <http://www.opengis.net/ont/geosparql#> | ||
| SELECT ?feature ?function ?geometry | ||
| PREFIX ex: <http://example.org/ns#> |
There was a problem hiding this comment.
Surely this is not an appropriate namespace for hasWKB?
There was a problem hiding this comment.
Is the name of this file misleading? How about get_greenspace_geometry.sparql?
…tion for Singaore use and update generic function lib to take trip-detection results and do further calculation
…rovisional trip detection
… unexpected spacing, remove this space
…dle when it extracted from timeline app
| BIND(SUBSTR(STR(?givenTime), 1, 4) AS ?timeYear) | ||
| ?be a fh:BusinessEstablishment ; | ||
| geo:hasGeometry ?geometry . | ||
| FILTER(CONTAINS(STR(?geometry), CONCAT("/", ?timeYear))) |
There was a problem hiding this comment.
Extracting information from an IRI is not recommended
| df = df.rename(columns={ | ||
| "column1": "SPEED", | ||
| "column2": "DISTANCE", | ||
| "column3": "HEIGHT", | ||
| "column4": "HEADING", | ||
| "column5": "LATITUDE", | ||
| "column6": "LONGITUDE", | ||
| "column7": "POINT" | ||
| }) |
There was a problem hiding this comment.
The sequence of this list is not guaranteed to be the same because it is a Map in TimeSeriesClient, this should not be hardcoded. Also refer to the next comment
|
General comment about obtaining time series data, it is not intended for developers/agents to obtain the data via SQL directly. There is a TimeSeriesClientFactory class that will generate the TimeSeriesClient with the correct time class (e.g. Instant, Integer, Double) and also the correct RDB client (TimeSeriesRDBClientWithReducedTables or TimeSeriesRDBClient). For getting time series data, there are methods such as getTimeSeries and getTimeSeriesWithinBounds. |
| self.logger.info(f"[fetch_env_data] Cache hit for env_data_iri: {env_data_iri}") | ||
| return self.env_data_cache[env_data_iri] | ||
|
|
||
| if feature_type.upper() == "POINT" and dl_lower.startswith("food hygiene rating") and reference_time is not None: |
There was a problem hiding this comment.
I think this entire if-else block can be made more concise and explained more clearly via comments or in the readme. E.g. there are many things that can be retrieved via a single query, rather than choosing the appropriate query via different if-else blocks.
This avoids issues such as get_point_generic being out-of-date relative to absolute_time_filter, which is the case at the moment
| mappingId GS-Geometry-details | ||
| target geo:Geometry{id} geo:asWKT "{wkt}"^^geo:wktLiteral ; ex:hasWKB "{wkb_hex}"^^xsd:string ; geo:crs <http://www.opengis.net/def/crs/EPSG/0/27700> . | ||
| source SELECT "id", "wkb_geometry" AS "wkb_hex", ST_AsText("wkb_geometry") AS "wkt" | ||
| FROM "GB_GreenspaceSite" |
There was a problem hiding this comment.
I don't think it is a good idea to obtain WKB (the binary format from PostGIS), the conventional way should be to process WKT literals.
Further to this, the GeoSPARQL standard to include CRS is in the WKT literal itself, i.e.
geo:Geometry{id} geo:asWKT "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> {wkt}"^^geo:wktLiteral
Based on my experience dealing with GeoSPARQL in Ontop, I think it's best to pre-convert everything into 4326 and not include the CRS IRI in the WKT literals at all because Ontop does not deal with it very well when there are multiple coordinate reference systems within a single instance of Ontop.
… in exposure calculation as a flag to show incomplete calculation
No description provided.