Hi,
there's an issue with the EPSG database that has been bothering
me for quite some time: the DMS unit.
The EPSG guidance defines the DMS unit as follow:
--
To allow coordinate operation parameter values given by their
Okay I sorted out a good way forwards and should be able to commit when Andrea
is ready. Going to pull the same trick used for Query; make MapContext an
actual class; which DefaultMapContext can extend. Does not really solve our
naming issue but does improve readability.
Jody
On 13/06/2010,
On 13/06/2010, at 5:19 PM, Andrea Aime wrote:
My guess is that anybody using a CRS with DMS unit is actually storing
the data in decimal deegrees, and that providing actual support for
the DMS unit transformation would just result in confused users.
2150 is one of such codes, if I look at
Wanted to introduce you to Crag from the uDig project - who cheerfully asked
me how geotools / osgi relationship was going. When he last checked in Harald
was working on it (but as you saw on that page Harald left instructions and
thus nothing has happened).
Sorry, I'm kind of busy right
Jody Garnett ha scritto:
On 13/06/2010, at 5:19 PM, Andrea Aime wrote:
My guess is that anybody using a CRS with DMS unit is actually storing
the data in decimal deegrees, and that providing actual support for
the DMS unit transformation would just result in confused users.
2150 is one of
b) alternatively, add a flag to control the DMS/degree behavior.
I would prefer to add a flag; even if the default value is true.
Cool. Any reasoning behind the preference?
Yeah; we are making an assumption - I would like the ability for users to make
the assumption the other way if they
Jody Garnett ha scritto:
b) alternatively, add a flag to control the DMS/degree behavior.
I would prefer to add a flag; even if the default value is true.
Cool. Any reasoning behind the preference?
Yeah; we are making an assumption - I would like the ability for users to
make the
Jody Garnett ha scritto:
b) alternatively, add a flag to control the DMS/degree behavior.
I would prefer to add a flag; even if the default value is true.
Cool. Any reasoning behind the preference?
Yeah; we are making an assumption - I would like the ability for users to
make the assumption
Jody Garnett ha scritto:
Jody Garnett ha scritto:
b) alternatively, add a flag to control the DMS/degree
behavior.
I would prefer to add a flag; even if the default value is
true.
Cool. Any reasoning behind the preference?
Yeah; we are making an assumption - I would like the ability for
On 14/06/2010, at 1:31 AM, Andrea Aime wrote:
Correct; I would phrase it as. When true we assume that DMS entries
are understood to be represented as decimal degrees; this assumption
is shared by many applications but may not be correct for your
dataset. When false we carefully do not assume
Hi,
I'm skimming through the proposal quickly and noting down
the things that do look odd.
Premise: the work looks sound and should clean up things
significantly. I like it, past some issues I'm going to
list in this mail.
Map - really bad name (tm), we should not clash with
java own
Thanks for the feedback Andrea! Some comments inline...
On 14/06/2010, at 6:18 AM, Andrea Aime wrote:
Map - really bad name (tm), we should not clash with
java own classes (yes, packages keep them apart,
but code completion gets confusing)
Agreed.
Solution - I am thinking of
On 09/06/10 22:37, Jody Garnett wrote:
Ben I notice you have a FeatureSourceMapLayer - I don't think this is needed
after the refactor; but I have no good way of testing.
Jody, I suspect you are right. This class was introduced as part of the
refactoring to support the DataAccess API. I have
On 14/06/10 13:30, Ben Caradoc-Davies wrote:
If you can replace all instances of FeatureSourceMapLayer with
DefaultMapLayer without
having to instanceof/cast, then it can be removed.
Let me go further: if you can do this, the class *should* be removed. It
was really an interim workaround,
14 matches
Mail list logo
