Acceptance Criteria for Current snapshot

[kshitijrajsharma]

An API endpoint, where the user can extract a certain OSM feature type and geometry type within the input polygon

Endpoint: /rawdata/current-snapshot/ POST Authenticated through OSM login

Source: Underpass

Sample Request Body:

{
  "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [
              71.08154296875,
              34.125447565116126
            ],
            [
              71.83959960937499,
              34.125447565116126
            ],
            [
              71.83959960937499,
              34.615126683462194
            ],
            [
              71.08154296875,
              34.615126683462194
            ],
            [
              71.08154296875,
              34.125447565116126
            ]
          ]
        ]
      }
,
  "outputType": "geojson",
  "columns": {},
  "osmTags": {},
  "osmElements": [],
  "geometryType": []
}

Acceptance Criteria:

1. Geometry

• Required field
• Can be a polygon
• Polygon size limited to 5000sq.km - Tasking Manager threshold is 5000 sq.km

2. Geometry Type

• Feature parity with Export Tool stack
• Supports Point, LineString, MultiLineString, Polygon, MultiPolygon
• Targeted for GIS users
• Not a required field
• Validation:
  • Both OSM element and geometry type inputs are not allowed in the same query
  • Only one input field is accepted

3. OSM Elements

• Supporting Overpass API geometry types
• Supports nodes/ways/relations
• Targeted for Overpass users
• Not a required field
• Validation:
  • Both OSM element and geometry type inputs are not allowed in the same query
  • Only one input field is accepted

4. Columns

• They are the attributes/properties associated with each OSM feature
• Could be name, contact, wheelchair access, opening hours and other possible tag combinations
• It is not to be used as a feature filter, rather a column/attribute extractor for individual features
• This lets extract specific attributes of an OSM feature
  • So that users could do further spatial exploration
  • So that there is feature parity with Overpass API for Export Tool
• Acceptable inputs: similar to OSM Tags

5. OSM Tags

• Defined as a dictionary
• Empty dictionary indicates all data
• It is composed of key-value pairs from OSM
• Value is always passed as a list - input is trimmed for spaces
• If the value is empty then it indicates all kinds of values for that particular key. Eg: building: [] indicates building = *
• Keys cannot be duplicated
• If the user supplied key-value does not exist in the DB, no data is returned. There is no validation done on the existence of tags

6. Output Type: GeoJSON - Compressed format: zip

[kshitijrajsharma]

After research I found out Hot export binds features based on the geometry also while looking at the common query from operpass turbo they need osm element type sometimes as well i.e. nodes,ways and relations Hence I have decided to support both of the case scenario To support Geometry Type, I have added following geometry type for now :

    POINT="POINT"
    LINESTRING = "LINESTRING"
    POLYGON = "POLYGON"
    MULTILINESTRING = "MULTILINESTRING"
    MULTIPOLYGON = "MULTIPOLYGON" 

User can request what type of geometry feature they want in return and we will be searching for those feature in all the relavant osm elements (nodes , ways , relation ) end user will not know about all those process what he / she will be getting is the features with those geometry . Let's say I have made request I want building polygons then I will be searching all the features with polygon geometry in relation , nodes , ways (wherever possible ) and deliver result back to them just like how hot export works right now Now for the second case scenario that user may want to get features based on the osm element types , I have added them as well as optional

    NODES = "nodes"
    WAYS_LINE = "ways_line"
    WAYS_POLY = "ways_poly"
    RELATIONS = "relations" 

Like this they can specify osm element type they want and we will be delivering based on their input all the geometries available Acceptance Criteria : Now we have two input fields i.e. osm_elements(nodes,ways_line,ways_poly,relations) , geometry_type(POINT,POLYGON,MULTIPOLYGON,MULTILINESTRING,LINESTRING)

• Only one input can be provided between those two fields either we need to pass osm_elements or you need to pass geometry_type , Both can not be passed at same time (since it will make confusion ) One of them is supported at a time

• If none of them is supplied or left no value in list It will deliver all the data with all geom type

• We cann't pass values rather than our specified enum list cc : @ramyaragupathy

• Related Commit for the work : 5ecd7311c88c51c7a7d297efd2c4821a2dcb26cc

[ramyaragupathy]

Original description updated to capture other fields included in this endpoint.

cc @itskshitiz321