You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@oodt.apache.org by "Paul Ramirez (Created) (JIRA)" <ji...@apache.org> on 2012/04/04 03:02:23 UTC
[jira] [Created] (OODT-436) GeoJSON Service for FileManager
GeoJSON Service for FileManager
-------------------------------
Key: OODT-436
URL: https://issues.apache.org/jira/browse/OODT-436
Project: OODT
Issue Type: New Feature
Components: file manager
Reporter: Paul Ramirez
Fix For: 0.5
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OODT-436) GeoJSON Service for FileManager
Posted by "Paul Ramirez (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245946#comment-13245946 ]
Paul Ramirez commented on OODT-436:
-----------------------------------
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).
> GeoJSON Service for FileManager
> -------------------------------
>
> Key: OODT-436
> URL: https://issues.apache.org/jira/browse/OODT-436
> Project: OODT
> Issue Type: New Feature
> Components: file manager
> Reporter: Paul Ramirez
> Labels: gsoc
> Fix For: 0.5
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OODT-436) GeoJSON Service for FileManager
Posted by "Cameron Goodale (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246008#comment-13246008 ]
Cameron Goodale commented on OODT-436:
--------------------------------------
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.
> GeoJSON Service for FileManager
> -------------------------------
>
> Key: OODT-436
> URL: https://issues.apache.org/jira/browse/OODT-436
> Project: OODT
> Issue Type: New Feature
> Components: file manager
> Reporter: Paul Ramirez
> Labels: gsoc2012
> Fix For: 0.5
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OODT-436) GeoJSON Service for FileManager
Posted by "Chris A. Mattmann (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246976#comment-13246976 ]
Chris A. Mattmann commented on OODT-436:
----------------------------------------
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.
> GeoJSON Service for FileManager
> -------------------------------
>
> Key: OODT-436
> URL: https://issues.apache.org/jira/browse/OODT-436
> Project: OODT
> Issue Type: New Feature
> Components: file manager
> Reporter: Paul Ramirez
> Labels: gsoc2012
> Fix For: 0.5
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OODT-436) GeoJSON Service for FileManager
Posted by "Paul Ramirez (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Ramirez updated OODT-436:
------------------------------
Labels: gsoc2012 (was: gsoc)
> GeoJSON Service for FileManager
> -------------------------------
>
> Key: OODT-436
> URL: https://issues.apache.org/jira/browse/OODT-436
> Project: OODT
> Issue Type: New Feature
> Components: file manager
> Reporter: Paul Ramirez
> Labels: gsoc2012
> Fix For: 0.5
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OODT-436) GeoJSON Service for FileManager
Posted by "Paul Ramirez (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246407#comment-13246407 ]
Paul Ramirez commented on OODT-436:
-----------------------------------
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.
> GeoJSON Service for FileManager
> -------------------------------
>
> Key: OODT-436
> URL: https://issues.apache.org/jira/browse/OODT-436
> Project: OODT
> Issue Type: New Feature
> Components: file manager
> Reporter: Paul Ramirez
> Labels: gsoc2012
> Fix For: 0.5
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira