|
|
Re: GIS comes to AMP.. [message #558409 is a reply to message #552883] |
Sun, 12 September 2010 14:34 |
Werner Keil Messages: 1087 Registered: July 2009 |
Senior Member |
|
|
Hi,
I looked at the Gama Platform
<http://code.google.com/p/gama-platform/wiki/Xtext>, suggested in a nearby
thread.
Turns out, they have internal but very insufficient (simply int, long or
double conversion factors ;-) Measurement support via a class called Units.
And then there's another Units class, GAMA uses from GeoAPI, including an
older (unofficial) version of JSR-275, the precursor to Unit-API.
GeoAPI has recently migrated, and is in the process to use Unit-API 0.6 and
above, the latest release, also used by the current UOMo draft.
Werner
|
|
|
Re: GIS comes to AMP.. [message #558416 is a reply to message #558409] |
Sun, 12 September 2010 16:09 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Thans for all of the info Werner..
Werner Keil wrote on Sun, 12 September 2010 10:34 |
Turns out, they have internal but very insufficient (simply int, long or
double conversion factors Measurement support via a class called Units.
|
Yes that sounds like a confusion between units of measure and machine representation. In any case I want to stay away from machine dependent specifications -- this seems to be conflating the idea of
Right now we only have a text field so that is obviously weak. But I wanted to leave it open for a good implementation. There are other threads around here and on amp-dev that people can look at WRT to Units of Measurement issues.
But we also need to have more generic representations for polygons, etc.. Currently there is a bit of that in the LoadAgentShape action but that's not really the place for it.
Quote: | And then there's another Units class, GAMA uses from GeoAPI, including an
older (unofficial) version of JSR-275, the precursor to Unit-API. GeoAPI has recently migrated, and is in the process to use Unit-API 0.6 and
above, the latest release, also used by the current UOMo draft
|
For implementation, I've been playing with GeoTools / uDIg and with a bunch of hacking that is working as a basic proof of concept. There are a lot of tools there potentially and uDig has an ecore representation, but it is mixed in with a lot of presentation and application stuff.
The GeoTools stuff has a another significant issue in that it is all based on SLD, which I find very fiddly and difficult to maintain. The basic idea is very sound though and perhaps there is something that could be adapted from that on the presentation side to enrich the AMF styles representation which right now is purposely very basic so that we can enrich it when the best approach is decided upon.
So my take is that the Runtime implementation (like Escape, etc..) stuff could be based on some of those APIs but any Meta-model (AMF) level stuff needs to go to the best standard possible and ignore any specific implementations. So I'd really appreciate any additional insight on both the implementation and Meta-Model. Especially, if there is a geo representation either in a) API form, XSD, or ideally an OMG M2 (?) spec with ecore semantics and that b) seems to likely to be the eventual winner for generic representations.
thanks again,
Miles
|
|
|
|
|
|
|
|
|
|
Where to discuss.. Re: GIS comes to AMP.. [message #559467 is a reply to message #559465] |
Thu, 16 September 2010 18:07 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Werner Keil wrote on Thu, 16 September 2010 13:51 | amp-dev at Eclipse.org I suppose?
I am not using those mailing lists here yet, but projects like STEM also
refer to them more often, so I may add a few more to my extensive list (at
Google Groups, Java.net, SF.net etc.
|
See: http://eclipse.org/amp/documentation/contents/Support.html#I ssues
I'm actually finding that all of this is a pretty gray distinction. Here is my present thinking:
a) This is a good spot to discuss general improvements, requests for feedback, etc.. ideas, etc.. which is what we've been doing so far. Heuristic: it might be of interest to the broader community.
b) AMP-DEV is the right place to get into the nitty-gritty of how we would actually implement such a thing. For example, what are strengths and weaknesses of various implementations, why the hell isn't the build working, who is working on what, etc. Heuristic: broader community would be bored to tears.
c) Bugzilla is the right place to discuss specific implementations that we really intend to do. This is when we need to keep track of this in a disciplined way so that a consistent record of decisions are made. Heuristic: broader community cares about wether we are actually doing something about an issue.
differing interpretations are of course welcome..
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.06426 seconds