On geolocation, sensors and international standards
Martin Desruisseaux
martin.desruisseaux at geomatys.fr
Tue Mar 6 12:43:51 PST 2012
Hello Richard
Thanks for the reply. Knowing that there is some tentative plan for Q3 2013 is a
very interesting information.
JSR 293 (Location API 2.0) has been developed by Nokia, without any involvement
from OGC or ISO organizations as far as I know. Some JSR-293 API are specific to
mobile devices, for example LocationListener which give notify the application
when the user moved. However other API overlap with current international
standards. If JSR-293 were taken as a starting point, one possible approach
would be to rename and move some classes or methods in order to bring them
closer to standards. For examples:
_*Class javax.microedition.location.AddressInfo:*_
Overlaps the CI_Address class defined by the ISO 19115 international standard.
Note that ISO 19115 is one of the standards required by laws (the INSPIRE
program) in Europeans countries, so governmental applications in Europe are
required to be able to export their data in a CI_Address structure (in XML
documents). It doesn't mean that applications have to store internally their
data that way, but they must be able to export their addresses that way.
The international standards are defined by UML schema. We translated those
schema to Java interfaces in the GeoAPI project. While the process of
translating UML to Java involves some arbitrary choices, the result should be (I
think) a good mirror of what the international standard is. For the above cited
CI_Address class, our proposed translation to Java interfaces is there:
http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/citation/Address.html
Note that it is acceptable to take a profile of those standards. ISO 19115
defines about 100 classes only about metadata (not counting referencing,
geometry, images...); JavaFX probably doesn't want all of them.
_*Class javax.microedition.location.Coordinates:*_
Duplicates DirectPosition defined by ISO 19107
(http://www.geoapi.org/3.0/javadoc/org/opengis/geometry/DirectPosition.html).
Except that the JSR-293 class is restricted to WGS84 (see discussion below) and
also provides string representations of a coordinate, which I think should be
the work of a separated class (like the separation between Number and NumberFormat).
_*Class javax.microedition.location.GeographicArea and its subclasses:*_
Overlaps GM_Geometry defined by the ISO 19107 international standard
(http://www.geoapi.org/snapshot/pending/org/opengis/geometry/Geometry.html). I
think that the main issues with the JSR-293 GeographicArea class are:
*
The Coordinate Reference System is restricted to geographic coordinates on
the WGS84 datum. Some other geographic protocols like GeoJSON went that way
(dealing with map projections is sometime perceived as a useless
complication) and came to realize the limitations. I would bet that many
users will request at least the support of Google Mercator projection. I
think that a non-trivial application will also needs to deal with the map
projection mandated by the national agency of the country where the
application is running, since the Map Projection to use for governmental
publications in a particular country is often mandated by law.
*
The GeographicArea class is two-dimensional in spirit. Even if their
coordinates carry an altitude value, I don't think it is really used since
objects of kind Rectangle, Polygon and Circle are geometries on a plane. We
sometime call such API "2½ dimensional". Note that this is similar to the
Java Topology Suite library (the most well-known Open Source Java library
for geospatial geometric objects -
http://www.vividsolutions.com/jts/JTSHome.htm). In contrast, ISO 19107 can
express 1D (curves), 2D (surfaces) or 3D (solids) objects. Admittedly, this
brings a whole bunch of complexity to ISO 19107.
_*Interface javax.microedition.location.services.Map:*_
Overlaps the Web Map Service (WMS) specification. While the WMS specification is
mostly for the communication between a web server and a client application, the
purpose seems to be quite similar.
Probably more overlaps could be found. In particular, I did not investigated the
"sensor" parts (which is also subject of OGC standards). Maybe a possible
working process could be as below?
* Put some starting point (eventually derived from JSR-293) on a Mercurial or
Git repository somewhere.
* Refactor in an iterative process for bringing the classes as close as
possible to international standards.
* Once JavaFX feels comfortable with the selected classes, call that a "GeoAPI
profile" or "GeoAPI core" (I have been asked - by Oracle among others - to
split GeoAPI into "core" and "extensions" parts).
* I would submit that profile or core to OGC for standardization (as a
revision of current GeoAPI standard), as a join submission with Oracle if
there is interest.
Regards,
Martin
Le 06/03/12 19:25, Richard Bair a écrit :
> Hi Martin!
>
> I think it would be wonderful to have this kind of interaction in JavaFX. Our plans are fuzzy in this area at present (the given feature is something for 3.0 which is 3Q 2013). The basic assumption we're starting with is to use the relevant JavaME JSRs as a starting point. I'm becoming familiar with these things but I am not yet fully up to speed :-). How much of the work by these different organizations have been standardized in Java ME?
>
> Thanks
> Richard
>
>> This is my first post on the JavaFX mailing list. To present myself briefly, I'm doing Java programming since 1997. Before that, I have done 7 years of C/C++ and a bit of Fortran, MatLab and assembler.
>>
>> In the "/New Features Proposed for JavaFX/" section from the http://javafx.com/roadmap/ page, we can read "/New UI controls, including (...) Map control are under consideration/" and "/JavaFX will incorporate support for on-device sensors, including (...) geo-location/". I have also read about a JavaFX demo running on mobile device in a previous JavaOne meeting. Some members (including myself) from the Open Geospatial Consortium (OGC) are very interested in those geo-location and sensor eventualities - while I understand it is not yet committed plan.
>>
>> The Open Geospatial Consortium (http://www.opengeospatial.org) is an international industry consortium of 444 companies, government agencies and universities participating in a consensus process to develop publicly available interface standards. OGC Standards support interoperable solutions that "geo-enable" the Web, wireless and location-based services and mainstream IT. Oracle is a principal member of OGC and has been a key player in the development of ISO 19107 (spatial geometry schema) among others.
>>
>> The GeoAPI project (http://www.geoapi.org) is an OGC working group that translate the OGC/ISO specifications into Java interfaces, and interpret those standards in an effort to meet the expectation of Java developers (naming conventions, integration with existing JDK API, etc.). In addition, the GeoAPI project provides a test suite allowing any GeoAPI implementations to run parts of the Geospatial Integrity of Geoscience Software tests (http://www.epsg.org/gigs.html) and some other tests.
>>
>> I suspect that JavaFX is aiming for something simpler than OGC/ISO standards. However, I wonder if it could be done as a profile of existing international standards, in collaboration with OGC working groups. I have been asked to modularize GeoAPI, and would be happy to work in collaboration with any JavaFX developer working on Map or Sensor API. Oracle has a strong vote power at OGC, since John Herring (an Oracle employee) is presents to most meetings.
>>
>> If there is any interest for JavaFX/OGC join work, maybe a possible approach would be to create a wiki page where some peoples list the desired functionality for Map and Sensor controls, and myself listing the elements from OGC/ISO standards that aim to provide those functionality? Then the complexity of those elements would be evaluated, and an eventually simplified profile proposed - trying to keep extension points so that users who need the full functionality (e.g. map projections) can still get it.
>>
>> As a side note, some of those OGC/ISO standards become European laws through the INSPIRE program. While a fully INSPIRE-compliant API is probably out of scope for JavaFX, I think that a JavaFX API consistent with the most basic OGC/ISO elements would have great value.
>>
>> Any though?
>>
>> Regards
>>
>> Martin Desruisseaux
>>
More information about the openjfx-dev
mailing list