Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POI Data model feedback #143

Open
dpatil-fw opened this issue Apr 23, 2024 · 5 comments
Open

POI Data model feedback #143

dpatil-fw opened this issue Apr 23, 2024 · 5 comments

Comments

@dpatil-fw
Copy link

We are building a POI editor for crowd sourcing GIS information.
We have designed our POI schema - https://github.com/dpatil-fw/dataModel.PointOfInterest
taking into consideration schema.org, OpenstreetMap data and https://smartdatamodels.org from Fiware.org

Thank you for providing this opportunity to get public feedback on the OGC POI data model.

Here are some of the questions I have:

  1. Multilingual Support:
    How are multilingual names and descriptions handled in the POI model?

  2. Enums Standard:
    Are there plans to support Standard Enums in the model?
    For Eg: https://schema.org/MedicalSpecialty

  3. Multidimensional Data:
    How are places at the same location(latitude, longitude) but different height/ depth handled in the model?
    For eg, places on flyovers(streetlight) or underwater POI etc

  4. Containment:
    If a POI contains another, like a building at a location may contain multiple shops at the same level. How is this handled?

  5. Opening hours are part of the base standard model, is there a plan to add Payment info/ Currency info/ Ratings etc in the base model too?

@cmheazel
Copy link
Collaborator

Re Enums Standard. The short answer is no. After an extensive review of POI use cases we could not find any enums which were common. Our decision was to allow each user community to define their own extensions to the POI model. These extensions should reside in the POI Payload. Since the POI Payload is designed to be self-describing, this should allow local optimization while preserving interoperability.

@cmheazel
Copy link
Collaborator

Re multidimensional data - A POI is a Feature. As such, the geometry is as defined in ISO 19107. These geometries are n-dimensional. The number of dimensions, axis properties, units of measure, etc. are defined by the associated Spatial Reference System (ISO 19111). We have SRS defined for 2, 3, and even 4 (spacetime) dimensions. You can even have POI on the Moon or Mars.

@cmheazel
Copy link
Collaborator

Re, Containment - A POI is a Feature. A Feature can contain other Features, which can contain other Features, and so on. Containment is built in.

@cmheazel
Copy link
Collaborator

Re multilingual support - this issue is being discussed within the SWG. We are still working toward a consensus.

@cmheazel
Copy link
Collaborator

Re. opening hours - based on the use case analysis we performed early in this effort, the SWG concluded that it would be best to limit the Standard to that information needed to describe and manage the POI itself. Information which describes the resource (Feature) that the POI represents cannot be standardized without imposing unacceptable constraints on at least a few information communities.

However, the Standard does encourage re-use of existing data constructs. "Payment info/ Currency info/ Ratings etc" could be added if suitable standards for these constructs can be identified. At the least this issue can be addressed in the non-normative Users Guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants