OODT
  1. OODT
  2. OODT-436

GeoJSON Service for FileManager

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 0.8
    • Component/s: file manager
    • Labels:

      Description

      Create a GeoJSON service much like the GeoRSS service. The GeoJSON spec is fairly simple but will expand on the GIS functionalities of the FileManager. Supporting this will allow us to support things such as Feature, FeatureCollection, Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection. This would be the GeoRSS on steroids and should allow other properties to be associated with each feature.

      Fundamentally, we can think of each product type to map to a FeatureCollection and each product to be a Feature. Moreover, we can use this GeoJSON service endpoint to work in a couple of modes.

      The first would act as a layer which consisted of all products (Features in a FeatureCollection) and should support probably support paging or some other mechanism to limit the number of features returned (maybe zoom level).

      http://localhost:8080/geojson/

      {product_type}

      The next would act as the GeoJSON for a particular product (i.e. return a Feature):

      http://localhost:8080/geojson/{product_type}

      /

      {product_id}

      The config should allow different mappings per product type (i.e. different metadata mappings to the Feature).

      Given the GeoJSON spec we should also remember to map the id property in the Feature to the product id. Once this is completed we should be able to easily plug the service into anything that supports GeoJSON and a great demonstration would be to do this in Leaflet http://leaflet.cloudmade.com/examples/geojson.html.

        Activity

        Paul Ramirez created issue -
        Hide
        Paul Ramirez added a comment -

        The type of geometry for a given Feature should be flexible and driven by config that maps back to a metadata field. If necessary a requirement could be that the metadata field be in WKT http://en.wikipedia.org/wiki/Well-known_text.

        Adding this service will also enable us to visualize the products in QGIS as adding a vector layer supports a reference to GeoJSON.

        One extension to the first service endpoint is that it could support some simple filtering or a query parameter that could be passed on to the FileManager to create custom GeoJSON endpoints (i.e. dynamic layers).

        Show
        Paul Ramirez added a comment - The type of geometry for a given Feature should be flexible and driven by config that maps back to a metadata field. If necessary a requirement could be that the metadata field be in WKT http://en.wikipedia.org/wiki/Well-known_text . Adding this service will also enable us to visualize the products in QGIS as adding a vector layer supports a reference to GeoJSON. One extension to the first service endpoint is that it could support some simple filtering or a query parameter that could be passed on to the FileManager to create custom GeoJSON endpoints (i.e. dynamic layers).
        Paul Ramirez made changes -
        Field Original Value New Value
        Labels gsoc gsoc2012
        Hide
        Cameron Goodale added a comment -

        Hey Paul,

        I quickly browsed the geoJSON spec here: http://www.geojson.org/geojson-spec.html

        Is the intention of the service to return geoJSON with all of a product's metadata listed in the 'properties' element within a 'Feature'? This seems like the most likely place since the properties element is able to store data as key: value pairs, and multi-values could be encoded as a JSON array.

        This looks like a really cool issue. Glad you created it.

        Show
        Cameron Goodale added a comment - Hey Paul, I quickly browsed the geoJSON spec here: http://www.geojson.org/geojson-spec.html Is the intention of the service to return geoJSON with all of a product's metadata listed in the 'properties' element within a 'Feature'? This seems like the most likely place since the properties element is able to store data as key: value pairs, and multi-values could be encoded as a JSON array. This looks like a really cool issue. Glad you created it.
        Hide
        Paul Ramirez added a comment -

        Yep, that would be the intent. The config should indicate which properties to flow back into the GeoJSON that way you don't have to send all the properties. Some simple renaming facilities might be nice too but not necessary on the first cut.

        Given this approach we'd also have a lightweight way to visualize a representation of the product on the map and make that choice at the product type level.

        One further note here is that the endpoint for the FeatureCollection (i.e. http://localhost:8080/geojson/

        {product_type}

        ) should support for responding with a compressed GeoJSON FeatureCollection, as this could get quite large.

        Show
        Paul Ramirez added a comment - Yep, that would be the intent. The config should indicate which properties to flow back into the GeoJSON that way you don't have to send all the properties. Some simple renaming facilities might be nice too but not necessary on the first cut. Given this approach we'd also have a lightweight way to visualize a representation of the product on the map and make that choice at the product type level. One further note here is that the endpoint for the FeatureCollection (i.e. http://localhost:8080/geojson/ {product_type} ) should support for responding with a compressed GeoJSON FeatureCollection, as this could get quite large.
        Hide
        Chris A. Mattmann added a comment -

        Hi Guys, this sounds awesome. Let's use Apache CXF and its implementation of JAX-RS for this. We use it in CAS curator, and I recently also baked it into Tika via TIKA-593.

        Show
        Chris A. Mattmann added a comment - Hi Guys, this sounds awesome. Let's use Apache CXF and its implementation of JAX-RS for this. We use it in CAS curator, and I recently also baked it into Tika via TIKA-593 .
        Hide
        Chris A. Mattmann added a comment -
        • push out to 0.6
        Show
        Chris A. Mattmann added a comment - push out to 0.6
        Chris A. Mattmann made changes -
        Fix Version/s 0.6 [ 12323845 ]
        Fix Version/s 0.5 [ 12320441 ]
        Hide
        Chris A. Mattmann added a comment -
        • push to 0.7
        Show
        Chris A. Mattmann added a comment - push to 0.7
        Chris A. Mattmann made changes -
        Fix Version/s 0.7 [ 12323889 ]
        Fix Version/s 0.6 [ 12323845 ]
        Lewis John McGibbney made changes -
        Fix Version/s 0.8 [ 12326811 ]
        Fix Version/s 0.7 [ 12323889 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Paul Ramirez
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development