W3C home > Mailing lists > Public > public-sdw-wg@w3.org > May 2016

Re: How to proceed with work on the spatial ontology task?

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Fri, 27 May 2016 10:54:44 +0200
Message-ID: <CAFVDz40SXJU=psaUW5NHJZu46zDEYJq2X=9bWsoV3n8ofDvoPQ@mail.gmail.com>
To: Linda van den Brink <l.vandenbrink@geonovum.nl>
Cc: Joshua Lieberman <jlieberman@tumblingwalls.com>, SDW WG Public List <public-sdw-wg@w3.org>
2016-05-26 14:42 GMT+02:00 Linda van den Brink <l.vandenbrink@geonovum.nl>:

> Hi all,
>
> I haven't had the time to really follow this, but we could spend some time
> on the subject at the next SDW BP subgroup telecon. If Frans/Josh are
> present to lead the subject?
>

Sure, this is a subject worhty of broad attention.

Regards,
Frans



>
> Linda
>
> -----Oorspronkelijk bericht-----
> Van: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu]
> Verzonden: woensdag 25 mei 2016 14:10
> Aan: Frans Knibbe
> CC: Joshua Lieberman; Rob Atkinson; SDW WG Public List
> Onderwerp: Re: How to proceed with work on the spatial ontology task?
>
> On 24/05/2016 11:57, Frans Knibbe wrote:
> > [snip]
> >
> > I am glad you see a way forward that is approaching a satisfactory
> > level of elegance. But I wonder if the approach you suggest leaves
> > room for broader use of the geometry concept, particularly:
> >
> >  1. Allow geometry descriptors to be used for datasets of geometry
> >     collections (e.g. express that all geometries in a dataset are 3D
> >     points and have CRS X).
> >  2. Allow geometry to use a non-earth CRS (e.g. Mars, a building, a
> >     microscope slide, a piece of paper).
> >  3. Allow geometry to exist without a spatial thing (e.g. a drawing I
> >     make in Inkscape which does not represent any real world spatial
> thing).
> >
> > I also wonder if this improves options for compatibility with basic
> > geo and neogeo.
> >
> > And I would like to note that I expanded the wiki page
> > <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL
> > >
> > a bit:
> >
> >   * I wrote that it makes sense to start with semantic foundations for
> >     the concept of geometry
> >   * I wrote that although not all relevant ISO standards are freely
> >     available, the schemas that they define can be viewed at
> >     http://www.isotc211.org/hmmg/HTML. It could be helpful that everyone
> >     is able to look up GM_Object from ISO-19117, for instance.
> >   * I added the current definition of geometry in GeoSPARQL
> >     <
> https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL#Definition_of_geometry>
> (it
> >     looks expandable enough)
>
> Thanks, Frans.
>
> I've also added to the same section the definitions of spatial object and
> feature, since they are correlated - geometry and feature are subclasses of
> spatial object, and they are mutually disjoint.
>
> I think it is good to have the full "picture", also considering our
> discussions on real-world / spatial thing, spatial object, feature.
>
> Andrea
>
>
> > Regards,
> > Frans
> >
> >
> >
> > 2016-05-23 15:57 GMT+02:00 Joshua Lieberman
> > <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>>:
> >
> >     I’ve thought about this a bit more and there doesn’t seem to be any
> >     significant problem with realizing GM_Object itself from 19107 as a
> >     first-class (Web) object. An identified geometric object with
> >     additional properties should also be compatible with GML, although
> >     GML also puts a lot of attributes on properties such as
> >     geometryPropertyType that would need to be class properties instead
> >     in rdf or in json. If the necessary properties can be added to
> >     GM_Object for discovery / governance / maintenance, this should
> >     simplify the pattern for one-to-many or many-to-many feature -
> >     geometry Web links.
> >
> >     The general pattern can also be collapsed further to an alternative
> >     simple geometry property equivalent to georss Simple, with strict
> >     defaults for cases where the simplest sort of positioning
> >     expressiveness is sufficient. Not sure how best to define this
> >     equivalence, however, beyond descriptively, as in GeoRSS and GML
> >     3.2.1 . Perhaps SPIN would help?.
> >
> >     Almost elegant.
> >
> >     Example:
> >
> >     myFeature a geo:feature ;
> >          rdf:about somefeatureURI
> >          geo:point  "X,Y”
> >          geo:centroid somegeometryURI
> >
> >
> >     myGeometry a  geo:point ;
> >                   rdf:about somegeometryURI
> >                   geo:geomtype “point"
> >                   geo:geomCRS <someCRSURL>
> >                   geo:geomresolution “someResolution"
> >                   geo:asWKT “POINT…”
> >                   geo:asJSON “[…]”
> >                   geo:asGML “<..>”
> >                   geo:centroidFor somefeatureURI
> >
> >
> >     where
> >
> >     geo:point  "X,Y” is equivalent to
> >
> >     geo:geometry [
> >                   geo:geomtype “point"
> >                   geo:geomCRS CRS84
> >                   geo:geomresolution “undefined"
> >                   geo:asPos “...”
> >     ]
> >
> >     Josh
> >
> >>     On May 20, 2016, at 6:47 PM, Rob Atkinson <rob@metalinkage.com.au
> >>     <mailto:rob@metalinkage.com.au>> wrote:
> >>
> >>
> >>     anyone have an elegant solution? Do we make a wiki page for this
> >>     specific problem?
> >>     I think we are at the heart of the issue here - something fairly
> >>     obvious with lots of bad ways of "solving", that we need expert
> >>     help find a best practice for
> >>
> >>
> >>     On Sat, 21 May 2016 at 08:15 Joshua Lieberman
> >>     <jlieberman@tumblingwalls.com
> >>     <mailto:jlieberman@tumblingwalls.com>> wrote:
> >>
> >>         Really don’t want to go down the reified property route with
> >>         this and we’d still have geompropmeta1, geompropmeta2,…but I
> >>         agree we have not achieved elegance here yet.
> >>
> >>         Josh
> >>
> >>
> >>>         On May 20, 2016, at 5:52 PM, Rob Atkinson
> >>>         <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>
> wrote:
> >>>
> >>>         Hi Josh
> >>>
> >>>         leaving the meta-meta-meta complexity dimension aside for the
> >>>         moment :-)
> >>>
> >>>         it sounds to me like you are making the case for reified
> >>>         geometry properties - with a convention that a simple
> >>>         property can have further properties declared against it with
> >>>         a reified property
> >>>
> >>>         something like:
> >>>
> >>>         myFeature a geo:feature ;
> >>>              foo:point  "X,Y"
> >>>              foo:geompropmeta [
> >>>                  foo:geomprop <foo:point>
> >>>                  foo:geomfunction <foovoc:Centroid>
> >>>                  foo:geomCRS <someCRSURL>
> >>>             ]
> >>>
> >>>         this is limited to one value of a property per feature.
> >>>         Or maybe there is a more elegant way of doing this?
> >>>
> >>>         R
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>         On Sat, 21 May 2016 at 02:07 Joshua Lieberman
> >>>         <jlieberman@tumblingwalls.com
> >>>         <mailto:jlieberman@tumblingwalls.com>> wrote:
> >>>
> >>>             We actually need to go up a level potential complexity
> >>>             here and then figure out how to make it as simple as
> >>>             possible. ISO 19107 was concerned with mathematically
> >>>             valid geometries. 19109 is concerned with making the
> >>>             separation between features and geometries by defining
> >>>             geometric properties of features. All good so far, but
> >>>             the step of creating a first-class geometric
> >>>             representation object (identifiable and linkable with its
> >>>             own properties) was not really considered either in the
> >>>             ISO specs or in the GML realization. We’ve had linked
> >>>             data schemes where data properties can be appended to
> >>>             reference features with their characteristic geometry,
> >>>             but not interchangeability of geometries for a given
> >>>             feature (or distributed recognition of features by
> >>>             linking data properties with independent geometric
> >>>             representations.
> >>>
> >>>             This means going from feature <- geometry to feature <->
> >>>             gm_representation <- geometry where gm_representation
> >>>             carries searchable properties such as geometry type,
> >>>             scale, crs, etc. and geometry can include alternate
> >>>             serializations such as SVG that require being combined
> >>>             with those properties.
> >>>
> >>>             Once such a feature realization is developed, one can
> >>>             certainly collapse it to convenience formulations for
> >>>             simpler cases, even point(lon, lat) as long as the
> >>>             equivalence is well defined. Not sure what ontology
> >>>             “dimension” this represents, or perhaps it’s a projection
> >>>             along the complexity dimension.
> >>>
> >>>             Josh
> >>>
> >>>
> >>>
> >>>
> >>>>             On May 20, 2016, at 5:04 AM, Frans Knibbe
> >>>>             <frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>>
> >>>>             wrote:
> >>>>
> >>>>             Hi Rob,
> >>>>
> >>>>             Have I understood correctly that you would like to see a
> >>>>             prioritization of options for improvement? My thought
> >>>>             was to first collect all possible ideas for improvement,
> >>>>             and then refine or prioritize them. But we could add a
> >>>>             section about priority of suggested changes now. I agree
> >>>>             that the semantic foundations have high priority.
> >>>>             Especially the definition of geometry, which is the core
> >>>>             concept. When geometry is defined, geometry descriptors
> >>>>             would follow from that more or less automatically. In
> >>>>             other words - when building something, it makes perfect
> >>>>             sense to start with the foundations.
> >>>>
> >>>>             It will be interesting to see if it possible to have a
> >>>>             definition of geometry that is not exclusively
> >>>>             geographic, that allows geometry to exist without a
> >>>>             related spatial thing, and that does not clash with
> >>>>             existing definitions.
> >>>>
> >>>>             Regards,
> >>>>             Frans
> >>>>
> >>>>
> >>>>
> >>>>             2016-05-20 8:39 GMT+02:00 Rob Atkinson
> >>>>             <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>:
> >>>>
> >>>>
> >>>>                 Hi - I looked at the page and I see the "first step"
> >>>>                 I was wondering about in the middle : under Semantic
> >>>>                 foundations.
> >>>>
> >>>>                 I'm not sure where to put my input as a result.
> >>>>
> >>>>                 The thread has highlighted that one issue is how
> >>>>                 geometries are bound to a feature - what are they
> >>>>                 are named (what property to use) and how those
> >>>>                 properties themselves are modelled.
> >>>>
> >>>>                 We also have many possible encodings, levels of
> >>>>                 detail, crs for each geometry - where is that
> >>>>                 information present in the binding - in the property
> >>>>                 definition, the datatype of the subject - e.g.
> >>>>                 skos:notation
> >>>>                 "GBP"^^a-uri-representing-the-set-of-currency-codes"
> >>>>                 or by reification of the property.
> >>>>
> >>>>                 I suspect the "flat" model where we put an
> >>>>                 out-of-band set of assertions about the equivalence
> >>>>                 of property names is going to be the easiest way to
> >>>>                 justify something as an actual "Practice" - but its
> >>>>                 still an open question IMHO about the best way to
> >>>>                 make it simple for clients. Finding and interpreting
> >>>>                 OWL to understand a random property name is quite a
> >>>>                 burden for the user - but easy for the publisher -
> >>>>                 even easier if they neglect to publish the
> >>>>                 definitions :-) This provider-centric pattern is I
> >>>>                 suspect a major reason Linked Data has had low
> >>>>                 levels of perceived value and adoption.
> >>>>
> >>>>                 To me establishing a well known binding of geometry
> >>>>                 to features is more important than standardisation
> >>>>                 amongst the many competing encodings - and has the
> >>>>                 beneift that we dont need to resolve the best way to
> >>>>                 encode now - even though we could make
> recommendations.
> >>>>
> >>>>                 So perhaps it comes down to testing whether
> >>>>                 geosparql geo:feature allows us to implement all we
> >>>>                 need, without introducing things we dont need - or
> >>>>                 if we need to define something else and somehow
> >>>>                 define an alignment with geosparql.
> >>>>
> >>>>                 thats the architect's viewpoint - how to make this
> >>>>                 work for users. We need the semantacists input in
> >>>>                 how best to achieve it.
> >>>>
> >>>>                 Left to my own devices - on the wiki page i'd put
> >>>>                 this the semantic foundations at the top of the list
> >>>>                 and push all the geometry-centric details into a set
> >>>>                 of options for implementation choices. I felt i
> >>>>                 should get feedback before going that far.
> >>>>
> >>>>                 Cheers
> >>>>                 Rob
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>                 On Thu, 19 May 2016 at 23:08 Joshua Lieberman
> >>>>                 <jlieberman@tumblingwalls.com
> >>>>                 <mailto:jlieberman@tumblingwalls.com>> wrote:
> >>>>
> >>>>                     One of the rabbit holes we will need to skirt is
> >>>>                     that everyone is an expert. While we may have
> >>>>                     good reason in theory and practice to separate
> >>>>                     feature - geometry - crs -serialization, many
> >>>>                     Semantic Web representers of space have seen no
> >>>>                     need for it for the application at hand and just
> >>>>                     collapse everything into one concept. This is
> >>>>                     one of the reasons that GeoRSS set up multiple
> >>>>                     formulations with assertions of equivalence -
> >>>>                     geo, simple, and GML. Then one could use a
> >>>>                     simple form and someone else could unpack it to
> >>>>                     do more with.
> >>>>
> >>>>                     Btw, using crs to enforce a serialization format
> >>>>                     has always been a terrible idea. Better to let
> >>>>                     geodesists and computer scientists each do what
> >>>>                     they do best and document it.
> >>>>
> >>>>                     Joshua Lieberman, Ph.D.
> >>>>                     Principal, Tumbling Walls Consultancy
> >>>>                     Tel/Direct: +1 617-431-6431
> >>>>                     <tel:%2B1%20617-431-6431>
> >>>>                     jlieberman@tumblingwalls.com
> >>>>                     <mailto:jlieberman@tumblingwalls.com>
> >>>>
> >>>>                     On May 19, 2016, at 08:51, Frans Knibbe
> >>>>                     <frans.knibbe@geodan.nl
> >>>>                     <mailto:frans.knibbe@geodan.nl>> wrote:
> >>>>
> >>>>>                     Thanks Andrea, I will add those ideas (I did
> >>>>>                     already add GeoShape). If you come up with more
> >>>>>                     ideas, please feel free to edit the wiki page.
> >>>>>                     Everyone can use it as a scratch pad.
> >>>>>
> >>>>>                     Regards,
> >>>>>                     Frans
> >>>>>
> >>>>>
> >>>>>                     2016-05-19 14:39 GMT+02:00 Andrea Perego
> >>>>>                     <andrea.perego@jrc.ec.europa.eu
> >>>>>                     <mailto:andrea.perego@jrc.ec.europa.eu>>:
> >>>>>
> >>>>>                         Thanks, Frans.
> >>>>>
> >>>>>                         My two cents:
> >>>>>
> >>>>>
> >>>>>                         1. Geometry serialisations / datatypes
> >>>>>
> >>>>>                         Other examples to be taken into account
> >>>>>                         include:
> >>>>>                         - Geohash
> >>>>>                         (https://en.wikipedia.org/wiki/Geohash)
> >>>>>                         - The geo: URI scheme
> >>>>>                         (
> https://en.wikipedia.org/wiki/Geo_URI_scheme)
> >>>>>                         - The serialisation used in Schema.org
> >>>>>                         <http://schema.org/> - see, e.g.,
> >>>>>                         http://schema.org/GeoShape
> >>>>>
> >>>>>                         On the other hand, I'm not sure the way
> >>>>>                         NeoGeo models geometries can be considered
> >>>>>                         a serialisation:
> >>>>>
> >>>>>
> >>>>> http://geovocab.org/doc/neogeo.html#vocabulary
> >>>>>
> >>>>>
> >>>>>                         2. Geometry descriptors
> >>>>>
> >>>>>                         I think we should include also the axis
> >>>>>                         order. This should be implicitly specified
> >>>>>                         by the CRS, but needs to be made explicit.
> >>>>>                         Also, some platforms may use a default axis
> >>>>>                         order irrespective of the CRS - if I'm not
> >>>>>                         mistaken this is the case in PostGIS, where
> >>>>>                         the default axis order is lon / lat.
> >>>>>
> >>>>>
> >>>>>                         Cheers,
> >>>>>
> >>>>>                         Andrea
> >>>>>
> >>>>>
> >>>>>                         On 19/05/2016 13:12, Frans Knibbe wrote:
> >>>>>
> >>>>>                             OK, I have just made a new wiki page
> >>>>>                             <
> https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL>
> >>>>>                             that links from the existing wiki page
> >>>>>                             about the agreed spatial ontology
> >>>>>                             <
> https://www.w3.org/2015/spatial/wiki/An_agreed_spatial_ontology>.
> >>>>>                             The
> >>>>>                             page is about a specfic approach to how
> >>>>>                             to achieve the spatial ontology
> >>>>>                             - we start with GeoSPARQL 1.0. That
> >>>>>                             choice marks a significant narrowing
> >>>>>                             of scope, and I hope the scope can be
> >>>>>                             narrowed even further. The new
> >>>>>                             wiki page is for collecting ideas on
> >>>>>                             how we could further develop
> >>>>>                             GeoSPARQL. Hopefully some people with
> >>>>>                             good ideas can contribute and
> >>>>>                             hopefully we can eventually align all
> >>>>>                             ideas. Josh and Rob: Do you think
> >>>>>                             the new wiki page can be a good way
> >>>>>                             forward, and if so, can you manage
> >>>>>                             to incorporate your ideas and
> >>>>>                             information? If you agree this is a step
> >>>>>                             in the right direction we could the
> >>>>>                             take some action to involve more
> >>>>>                             people in thinking along.
> >>>>>
> >>>>>                             Regards,
> >>>>>                             Frans
> >>>>>
> >>>>>
> >>>>>                             2016-05-19 2:56 GMT+02:00 Rob Atkinson
> >>>>>                             <rob@metalinkage.com.au
> >>>>>                             <mailto:rob@metalinkage.com.au>
> >>>>>                             <mailto:rob@metalinkage.com.au
> >>>>>                             <mailto:rob@metalinkage.com.au>>>:
> >>>>>
> >>>>>                                 Having a very lightweight ontology
> >>>>>                             that defines a "feature" would be
> >>>>>                                 a great start.  As a test case, I'd
> >>>>>                             like to explore defining an
> >>>>>                                 RDF-Datacube dimension using such
> >>>>>                             an ontology - the
> >>>>>                                 observation:featureOfInterest
> >>>>>                             ontology. Personally, I dont think
> >>>>>                                 importing the full ISO 19150
> >>>>>                             ontology is a workable strategy - but
> >>>>>                                 one could have annotation
> >>>>>                             properties (or an additional module) that
> >>>>>                                 handles the alignment to 19150.  At
> >>>>>                             the moment I see many attempts -
> >>>>>                                 but nothing accepted by the
> >>>>>                             community at large.
> >>>>>
> >>>>>                                 simply, one ought to be able to
> >>>>>                             look at a dimension defined against
> >>>>>                                 a datatype, and/or set of objects,
> >>>>>                             and discover that such objects a
> >>>>>                                 spatial features and thus the
> >>>>>                             dimension supports operations relevant
> >>>>>                                 to spatial features - such as find
> >>>>>                             the properties of such features
> >>>>>                                 and running a filter on them.
> >>>>>
> >>>>>                                 I'm happy to help shepherd this Use
> >>>>>                             Case through the emerging plan -
> >>>>>                                 and verify the solution is
> >>>>>                             implementable. I need this in the context
> >>>>>                                 of other BP work OGC is involved in.
> >>>>>
> >>>>>                                 Rob
> >>>>>
> >>>>>                                 On Thu, 19 May 2016 at 02:03 Joshua
> >>>>>                             Lieberman
> >>>>>                                 <jlieberman@tumblingwalls.com
> >>>>>                             <mailto:jlieberman@tumblingwalls.com>
> >>>>>                             <mailto:jlieberman@tumblingwalls.com
> >>>>>                             <mailto:jlieberman@tumblingwalls.com>>>
> >>>>>                                 wrote:
> >>>>>
> >>>>>                                     This is probably a type
> >>>>>                             locality for W3C - OGC collaboration, as
> >>>>>                                     we should develop a GeoSPARQL
> >>>>>                             change request and SWG charter
> >>>>>                                     that contains a proposed update
> >>>>>                             to the feature data ontology
> >>>>>                                     part at least, that the SDWWG
> >>>>>                             can then reference in BP. The
> >>>>>                                     charter could be considered at
> >>>>>                             the OGC June meeting. The
> >>>>>                                     technical challenge (besides
> >>>>>                             the usual simplicity vs capability)
> >>>>>                                       is that there is pretty good
> >>>>>                             consensus on the concepts and
> >>>>>                                     principles, but we’re divided
> >>>>>                             by the way those materialize in
> >>>>>                                     different encodings.
> >>>>>
> >>>>>                                     Josh
> >>>>>
> >>>>>
> >>>>>                                         On May 18, 2016, at 11:54
> >>>>>                                 AM, Ed Parsons <eparsons@google.com
> >>>>>                                 <mailto:eparsons@google.com>
> >>>>>                                         <mailto:eparsons@google.com
> >>>>>                                 <mailto:eparsons@google.com>>>
> wrote:
> >>>>>
> >>>>>                                         Frans I think it is up to
> >>>>>                                 you and Josh to suggest a way
> >>>>>                                         forward, I would suggest
> >>>>>                                 you focus on a very strict scope of
> >>>>>                                         documenting an ontology
> >>>>>                                 based on that used by GeoSPARQL,
> >>>>>                                         perhaps just start with a
> >>>>>                                 shared document/wiki for comment ?
> >>>>>
> >>>>>                                         Ed
> >>>>>
> >>>>>                                         On Wed, 18 May 2016 at
> >>>>>                                 10:42 Frans Knibbe
> >>>>>                                         <frans.knibbe@geodan.nl
> >>>>>                                 <mailto:frans.knibbe@geodan.nl>
> >>>>>                                 <mailto:frans.knibbe@geodan.nl
> >>>>>                                 <mailto:frans.knibbe@geodan.nl>>>
> >>>>>                                 wrote:
> >>>>>
> >>>>>                                             Dear chairpeople,
> >>>>> Josh,
> >>>>>
> >>>>>                                             In the teleconference
> >>>>>                                 of 2016-04-27
> >>>>>
> >>>>>                                 <
> https://www.w3.org/2016/04/27-sdw-minutes>
> >>>>>                                 we discussed
> >>>>>                                             the spatial ontology
> >>>>>                                 mentioned in the charter as a part of
> >>>>>                                             the BP deliverable.
> >>>>>                                 Although no official actions or
> >>>>>                                             resolutions were
> >>>>>                                 recorded, we did agree that working
> on
> >>>>>                                             this topic was needed,
> >>>>>                                 that the work would be separate
> >>>>>                                             from work on the BP
> >>>>>                                 document, that Josh and I would try
> to
> >>>>>                                             take point and that we
> >>>>>                                 would take the current GeoSPARQL
> >>>>>                                             standard as a starting
> >>>>>                                 point.
> >>>>>
> >>>>>                                             How can we take this
> >>>>>                                 forward? Should we first try to form
> >>>>>                                             a group of interested
> >>>>>                                 people? Or should we just start
> >>>>>                                             somewhere, for example
> >>>>>                                 by making a wish list for a next
> >>>>>                                             version of GeoSPARQL,
> >>>>>                                 and making that interesting enough
> >>>>>                                             for many people to get
> >>>>>                                 involved?
> >>>>>
> >>>>>                                             Regards,
> >>>>>                                             Frans
> >>>>>
> >>>>>                                         --
> >>>>>
> >>>>>                                         *Ed Parsons *FRGS
> >>>>>                                         Geospatial Technologist,
> >>>>> Google
> >>>>>
> >>>>>                                         Google Voice +44 (0)20 7881
> >>>>>                                 4501
> >>>>>
> >>>>> <tel:%2B44%20%280%2920%207881%204501>
> >>>>>
> >>>>>                                 <tel:%2B44%20%280%2920%207881%204501>
> >>>>>                                         www.edparsons.com
> >>>>>                                 <http://www.edparsons.com/>
> >>>>>                                 <http://www.edparsons.com/>
> >>>>> @edparsons
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>                         --
> >>>>>                         Andrea Perego, Ph.D.
> >>>>>                         Scientific / Technical Project Officer
> >>>>>                         European Commission DG JRC
> >>>>>                         Institute for Environment & Sustainability
> >>>>>                         Unit H06 - Digital Earth & Reference Data
> >>>>>                         Via E. Fermi, 2749 - TP 262
> >>>>>                         21027 Ispra VA, Italy
> >>>>>
> >>>>>                         https://ec.europa.eu/jrc/
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
> --
> Andrea Perego, Ph.D.
> Scientific / Technical Project Officer
> European Commission DG JRC
> Institute for Environment & Sustainability Unit H06 - Digital Earth &
> Reference Data Via E. Fermi, 2749 - TP 262
> 21027 Ispra VA, Italy
>
> https://ec.europa.eu/jrc/
>
>
Received on Friday, 27 May 2016 08:55:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:21 UTC