Hello all
Two weeks ago, we posted a request to the GeoTools PMC asking permission
to re-license portions of GeoTools 2.6. However since that time, we
reformulated our demand as a request to the OSGeo board to state
whatever the Contributor's rights, which is granted "perpetual,
irrevocable, w
Hello Ben
Thanks you very much for your reply. There is some notes in-line,
followed by a request to the OSGeo board and a modification of our
request to the GeoTools PMC.
Le 30/07/12 08:00, Ben Caradoc-Davies a écrit :
> although I am a member of the PMC, I am now writing as an individual:
>
Jody
My previous email was a question to the OSGeo board about the
interpretation of a particular paragraph of the copyright agreement, as
pointed by Frank. We understand that GeoTools has its own schedule,
consequently we didn't asked any decision about the 5% of "core" code
that we didn't wr
Le 27/07/12 16:24, Jody Garnett a écrit :
> Currently i am spending more of my volunteer time writing email with
> you then helping you at the moment.
Just for clarification: this phrase may give the impression that we are
having extensive private email exchange, which is not the case.
Marti
Hello all
I would like to know the board position on the interpretation below. Are
contributors who granted their copyright to OSGeo allowed to re-license
their own work to an other open source license? We have no problem in
waiting for the conclusion of OSGeo debate about the work done by othe
Le 27/07/12 01:31, Martin Desruisseaux a écrit :
> We were unsure about this interpretation, and thus asked to the board.
> We have always been told in the past to ask to the GeoTools PMC.
Just for clarification: I'm really not pointing to anyone since we have
been told that by man
Hello Frank
Le 27/07/12 00:46, Frank Warmerdam a écrit :
> "The Foundation hereby grants the Contributor the nonexclusive,
> perpetual, irrevocable, worldwide, royaltyfree,
> license to use, copy, prepare derivative works of, publicly display or
> perform, and distribute the Submission."
>
> I *
Hello Cameron
Le 27/07/12 00:37, Cameron Shorter a écrit :
I'd be interested to hear who voted from the Geotools PSC, and their
reasons for voting as they did.
Are you able to point at the IRC logs, or email conversation?
Alternatively invite the people with concerns to air their opinions.
Th
Board
As suggested, we posted our request on the GeoTools mailing list
(http://sourceforge.net/mailarchive/message.php?msg_id=29572383). The
GeoTools PMC had a meeting Monday, which resulted in 2 "inclined yes"
votes, 2 "inclined no" votes and one proposal to re-license GeoTools
too. We do no
Hello Jody
I'm understanding your concern. But I would also like to emphase that we
are talking about code written at 95% by myself, Geomatys or IRD - large
parts were written even before GeoTools 2 started -, that we are willing
to trim the remaining 5% using Subversion history, at that - like
Hello all
I'm Martin Desruisseaux, a former GeoTools 2 contributor and now a
developer of the Geotoolkit.org project (http://www.geotoolkit.org).
In our search for a community, we had a recent discussion with members
of the Apache Spatial Information System project
Hello Jody
Le 16/01/12 15:18, Jody Garnett a écrit :
> What I would like to do is make a Jira issue out of your request so we can
> track its progress.
Done, as a copy of the previous email:
https://jira.codehaus.org/browse/GEOT-4017
> If we need me to do the work as a GeoTools project member,
Martin Desruisseaux created GEOT-4017:
-
Summary: Asking permission to copy portion of code in the public
domain
Key: GEOT-4017
URL: https://jira.codehaus.org/browse/GEOT-4017
Project: GeoTools
ave the GeoTools PSC permission to put portions of above-cited classes in
the public domain?
Regards,
Martin Desruisseaux
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
htt
Hello all
There were talk recently about Coverage on both GeoAPI and GeoTools list, so I
take this opportunity to clarify a situation and anounce what may be a future
change.
Why org.opengis.coverage.grid.GridRange has been deprecated
---
Hello all
Simone Giannecchini a écrit :
> to start cleaning up things in geotools coverage module. This time is
> the turn of GridRange subclasses which become deprecated all of a
> sudden last summer with very little communication.
Just for completness for those who read the list, those classes
Ben Caradoc-Davies a écrit :
> That would be great! It may also be necessary to exchange source in both
> directions, so I encourage both the geotools and geotoolkit communities
> to endeavour to keep their licensing compatible.
Yes, the license is the same (LGPL 2.1) and the copyright owner the
Hello Ben
Ben Caradoc-Davies a écrit :
> Martin, are there any other Jira components to be handed over?
There is the also the referencing, metadata, widgets-swing, coverageio,
coverageio-netcdf, coverageio-hdf, openoffice, epsg-hsql and epsg-extension
modules. There is 106 JIRA tasks that are s
Jody Garnett a écrit :
> I am not content with your organizations lack of ability to work
> within the GeoTools project guidelines.
>
> The guidelines that shape how a community collaborates are as much a
> part of the GeoTools vision technically quality. You will find that we
> share the same vis
Hello Jody
Jody Garnett a écrit :
> We share this aim; we differ of accountability Vincent. While I was
> happy that Martin is finally making progress; I am sad that this was
> not reachable while working with community members such as myself.
>
> As I understand Martin's offer to roll back chang
nswer questions, if there are
any,
then I will probably sign off from the list as well.
Bye
Martin Desruisseaux
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified lice
Jody Garnett a écrit :
> Hi Andrea: I have released GeoAPI 2.2.0 ...
>
> The artifacts have been deployed to the osgeo repository (just like trunk):
> - http://download.osgeo.org/webdav/geotools/org/opengis/geoapi/2.2.0/
>
> The tag is created here:
> - https://geoapi.svn.sourceforge.net/svnroot/
Andrea Aime a écrit :
> It seems appropriate for the 2.5.5 release to depend on a well
> known GeoApi version in fact, yet I don't know what the status of
> the GeoApi 2.2 branch is (is it still in a state of flux?).
> I would prefer some comments from Jody on it.
I'm not aware of pending tasks f
Andrea Aime a écrit :
> - have both depend on a geoapi snapshot for the time being?
>would sure be nice to have an M3 instead of depending on
>a snapshot?
Given that M2 is a bit old, a guess that creating a M3 would be appropriate.
Would you like us to create this milestone?
Mar
Christian Müller a écrit :
> Simone, If your are attacking this CRS stuff, could you please make a design
> offering an API for CRS conversions of envelopes and images.
For the transformation of envelopes, there is this method:
http://javadoc.geotools.fr/snapshot/org/geotools/referencing/CRS.ht
Ben Caradoc-Davies a écrit :
> I recently upgraded to Maven 2.0.10. When Building GeoTools I have
> noticed these warnings:
>
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
>
> This looks like Windows brain-damage (that is t
Gabriel Roldan a écrit :
> As the build keeps broken while commits are being made may be we can
> upload the needed geoapi jar to the opengeo repository?
>
> would that be enough a workaround?
I have not watched the reason for the failures. Are they due to trouble
downloading the GeoAPI snapsho
Justin Deoliveira a écrit :
> The mess that resulted from the threaded EPSG work is unfortunate. But
> Simone is correct that there are processes in place to protect against
> this sort of thing. It is your job as the maintainer to demand a
> proposal, ask for patches, have people work on a bran
Simone Giannecchini a écrit :
> This is -THE- problem Martin, the modules are not YOURS (maintainer
> != owner), the modules are part of the project and being so someone
> else may change them providing that is follows the rules, which means
> proposal and everything. If you don't have time to re
Hello Andrea
Putting "geotidy" under a GeoTools umbrella (either as a separated Maven
project
or merged to SVN) is an offering that we make to the community, but as far as
we
(at geomatys) are concerned we have no obligation to do so. This offer has been
made repeatedly since the begining. If
Michael Bedward a écrit :
> One day I would love to see an "Analytical Coverage" in GeoTools.
> That would lend itself to working in Renderable mode. With that in
> mind, even though your suggested new names are informative I think I'd
> also lean towards keeping the old names.
Thanks :). I had s
Hello Mickael
I made a very first draft of documentation here:
http://geotidy.geomatys.fr/apidocs/org/geotools/coverage/processing/package-summary.html#package_description
It still insuffisient since Hudson trigged its build (at fixed time) before I
could complete more. But we could try to impr
Hello Justin
Justin Deoliveira a écrit :
> Sounds like you are making good progress. That said I would like to see
> a formal proposal with voting before any changes come back to geotools.
> Unfortunately the forking nature of how this work has been done
> represents a lot of risk to projects t
Hello Simone
For now I'm porting the GridCoverage classes with few changes (much less work
than I did for referencing), except replacing some deprecated methods by their
replacement. Once this part is done, we will merge geotidy with geotools as
described in my previous email, and we will test
Hello Jody
Jody Garnett a écrit :
> For my own sanity you may want to start putting together the proposal
> covering API change a bit before you are ready to merge.
For now, I have put together two level of informations:
* An overview level, trying to give an overview of the
main changes with
Hello all
Following on the JAI operation discussion, I mentioned that I'm working on
Operation2D / OperationJAI right now. Actually I'm porting them to geotidy. In
the process I rewrote yesterday the way the result of GridCoverage2D operations
can be cached (I realised that the implementation i
Hello Mickael
The timming is amazing, since I'm revisiting Operation2D and OperationJAI since
yesterday!
Michael Bedward a écrit :
> Currently, some JAI functions are wrapped in...
>
> - sub-classes of Operation2D (e.g. Resample)
>
> - sub-classes of OperationJAI (all the 'straight' wrappings
Affects Versions: 2.6-M1
Environment: All
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Priority: Minor
Attachments: esri_geotidy_diffs.txt
Some projection parameter names have an ESRI alias that doesn't match the name
EPSG factory now run on PostgreSQL 8.3 (with integer key - not yet prepared to
handle variants that use other kind of keys).
Tested with EPSG database version 6.18 (latest version at the time of
writting).
This has required some updates to the referencing module due to minor changes
in
the da
About Maven 2.0.10, there is a fair amount of enhancements but I thing that the
two ones below worth mentionning:
* mvn -o is now really offline. If Maven 2.0.9, it still tried to
download snapshots and failed if it can't download them.
* When there is many modules that are "on the same level
I known that CRS.decode(...,) and CRS.decode(..., true) are commonly used -
they
will not change. But are anyone using the same method with a "false" argumment
value?
In GeoTools 2.6 we have:
CRS.decode(..., true) : set FORCE_LONGITUDE_FIRST_AXIS_ORDER to TRUE
CRS.decode(..., false) :
Andrea Aime a écrit :
> I can commit it. I was tghinking of rolling a separate method
> setCode(preparedStatement, int index, String code)
> so that subclasses can override the defult behavior and use setString
> instead. That should handle the IGN specific case.
We can wait before making this met
Hello Jonathan
Milton Jonathan a écrit :
> Hmm, but it took me a little time to find it: it's
> in geoapi 2.2, not 2.3 right?
> http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/style/StyleFactory.html?is-external=true
> (I guess 2.3 was split, I don't know if there are javadocs around f
Hello Andrea
I had a quick look at the patch you posted at
http://jira.codehaus.org/browse/GEOT-2363 and I'm fine with it. If you have
that
change ready to commit on your local SVN, would you like to commit them?
Alternatively I can commit your patch if you prefer - at your choice, just let
m
Justin Deoliveira a écrit :
> What bothers me more is how changes to geoapi have been handled
> recently. In some cases ( like Ben's proposed changes ) it seems a
> formal proposal is needed. However in the case of recent style changes
> it seems breaking api is ok. It seems ambiguous to me.
I
Hello Andrea
Applying the patch sound fine them. Alternatively the timeout could also be put
to a yet smaller value (e.g. 1 second) - at your choice.
Martin
--
Open Source Business Conference (OSBC), March 24-2
Hello Andrea
The problem you are pointing can be solved in a simplier way...
> A deeper analysis shows an architectural problem with the sql
> based EPSG factories, in particular, they get a hold on a single
> SQL connection and try to perform every operation against it,
> without any possibilit
Hello Jive
Its look like that the switch to GeoAPI 2.3-SNASHPOT is causing issue; I'm
sorry
for that. Do you want me to take the hand on that?
Martin
--
Open Source Business Conference (OSBC), March 24-25, 200
Justin Deoliveira a écrit :
> This only affects geotools trunk correct? If so there should be no
> issues from our side.
Yes, as suggested by Jody GeoTools 2.5 stay unchanged on GeoAPI 2.2-SNAPSHOT.
We
can even do "pseudo-formal" release of GeoAPI 2.2 if this is useful to GeoTools.
Mar
Christian Müller a écrit :
> Do you have a possiblity to initialze this instance variable with the
> default locale (Sun sdk does it, ibm sdk not) ?
I was expecting this locale to get the value of the actual Locale found by
ResourceBundle.getBundle(...), which may or may not be the default local
Hello Christian
Thanks for your encouragement with java.util.concurrent. I'm quite pleased with
it. It took me a few hours to get used to think in terms of "putIfAbsent" or
"replace" instead of the usual "get" and "put", but once I get used it was
really a charm.
Christian Müller a écrit :
> D
Jody is ready to commit on the GeoTools SVN an upgrate from GeoAPI dependency,
from 2.2-SNAPSHOT to 2.3-SNAPSHOT.
There is at this time absolutly no API change. The only impact is that the
Maven
dependency declared in the pom.xml file, which was "geoapi", would become
"geoapi-pending" for most
I'm close to the end. The port of the EPSG factory is under progress and I'm at
last looking at the "Threaded EPSG factory" work which was done a few years
ago.
In the process I rewrote some piece of code in order to take advantage of the
java.util.concurrent package, which we were not allowed
Hello Jody
I'm fine with aligning GeoTools trunk on GeoAPI 2.3-SNAPSHOT and keeping GeoAPI
2.2-SNAPSHOT for GeoTools 2.5. The change on trunk can be applied at any time
people wish. If you already did that, maybe you can just commit after we get
the
okay from other?
Martin
--
Jody Garnett a écrit :
> I would like to migrate trunk to track the GeoAPI 2.3-SNAPSHOT; we have
> to add an additional dependency to match the split into geoapi and
> geoapi-pending.
As far as GeoTools is concerned, the only change is to replace the "geoapi"
Maven dependency by "geoapi-pending
Hello Jody
Thanks a lot for your email. There is a lot of content to think about. I can
not
really make a useful answer right now, since I still working on the referencing
module. However there is a link I could submit:
Jody Garnett a écrit :
> - with respect to Jira. Perhpas Martin can "resol
Hello Jody
Jody Garnett a écrit :
> Your example answered my question; as far as I know:
> - GeoTools 2.5 uses a specific milestone release of GeoAPI-2.2.
> - GeoTools 2.6 can make the change you describe above
Actually at Andrea's suggestion I increased the version number to 2.3, so
GeoTools (b
Andrea Aime a écrit :
> GeoTools targets Java 5 at the moment. Due to differences in how
> Java 5 and Java 6 behave (the way they handle math calculations
> for example) some tests are failing in Java 6.
Andrea is right. I noticed issues in projection formulas around expressions
like
"atan(v1) /
Hello Mickael
Michael Bedward a écrit :
> I just noticed a couple of recent messages on the 'geotools
> discussion' list and pointed the posters to the users' list. Can we
> close the discussion list so that people don't get lured into the void
I just had a look at the SourceForge admin page. Th
Didrik Pinte a écrit :
> Am I really forced to load JAI even if I do not need any imaging
> functions ?
No, you get the warning but can ignore it - this is just one particular
transform which will not be available.
In the next version of referencing module I'm working on
(http://geotidy.geomat
Hello
epsg-wkt.jar is deprecated and will be removed. Is there any chance you could
test with epsg-hsql.jar instead? We use EPSG:27572 often with no problem when
using the HSQL database.
Otherwise we would need to open epsg.properties in the epsg-wkt.jar file, look
for the 27572 entry and try
Simone Giannecchini a écrit :
> IMHO we should make use of the OSGEO maven repo as our primary repo to
> make the transition definitive.
Sound good to me, but I still don't have write access to OSGEO. So I just
deployed on list.refractions.net for now.
Martin
---
Its look like that we have 3 Maven repositories around:
http://download.osgeo.org/webdav/geotools/
http://lists.refractions.net/m2/
http://maven.geotools.fr/repository/
The one on geotools.fr is a mirror of the refraction's one, synchronized every
night. But what is the relationship bet
Hello Rob
Rob Atkinson a écrit :
> it would be great for the current round of development to be able to
> propose changes if needed to the realtively-new-and-untested ISO
> Feature interfaces in a more flexible environment than the stable
> components.
I hope that leaving those interfaces in the
Hello Ben
Ben Caradoc-Davies a écrit :
> Martin, we would very much like to change GeoAPI so that it can support
> XSD complexType with simpleContent. At the moment, we are stuck with an
> Ugly Hack: smuggling the simple content in a fake property. I am yet to
> write the encoder to unpack this
Andrea Aime a écrit :
> Given the kind of change it seems sensible to pop up the number to 2.3?
Yes I had some hesitation but its look like preferable.
> In many ways this seems to represent the beginning of a different way of
> managing GeoApi, from consesus based on a mailing list to something
I'm posting this email on the GeoTools mailing list in case peoples missing it
from the GeoAPI mailing list.
Last week, I posted an annoucement saying that I was planning to split GeoAPI
in
two modules. I waited one week in case someone would object. Since I got no
objection, I plan to process
Christian Müller a écrit :
> I never succeeded running a "mvn clean install" on an IBM sdk. Can anybody
> notify me if we succeed with sun java 6. Afterwards I will try it with the
> ibm sdk (necessairy for all users running geotools/geoserver in Websphere or
> using geotools on AIX, Linux/ppc o
Maybe we could revert and re-enable the tests? Actually I'm neutral on this
issue, but if I'm understanding right, the tests were disabled for Javadoc
generation? If so, the path of less resistance may be to suffer the javadoc
problems for now and get them solved (as far as referencing is concer
Sunburned Surveyor a écrit :
> I wonder if Geotools look something like this in the future:
>
> A set of core modules maintained by the community using Maven and other tools.
> A set of modules maintained by individuals or teams that utilize code
> from the core Jars. Each module maintainer would
Michael Bedward a écrit :
> Some of us are going to be stuck with Java 5 for a while yet.
Well, as said in my previous email a "geotidy for geotools" mercurial clone may
be required anyway in order to reinject some deprecated methods that I removed.
Keeping this clone compatible with Java 5 will
Michael Bedward a écrit :
> 2009/2/5 Martin Desruisseaux wrote:
>> Not only Linux distributions. Maven 2.0.6 is bundled "out of the box" in
>> MacOS 10.5.
>>
>
> Is it ? Are you sure ?
Yes, I'm on mac since a few weeks :) (but still loving Linux and wi
Andrea Aime a écrit :
> That's just because you're cherry picking the epsg factory you decided
> to use. Really make one big jar with all the epsg factories we have in
> the build and I don't believe it'll be working.
Right... But this is an other thing that I'm fixing.
Martin
-
Jody Garnett a écrit :
> My understanding was Java 6 was now available for the mac; although
> perhaps it is included with the latest operating system?
Java 6 is now bundled in MacOS 10.5, together with Maven 2.0.6 and Subversion
1.4.
Martin
---
Jody Garnett a écrit :
> Martin also suggested we could simplify - martin do you have specific
> ideas of complexity that can be stripped out of our maven configuration?
We could try to reduce the amount of profiles as much as we can. For example
the
"ordinary tests" vs "OnlineTest" setting cou
Jody Garnett a écrit :
> To add fuel to a slightly different fire - the maven plugin system is
> magic to the point of being unstable. There is a branch of maven that
> "hard codes" the plugins used so you can get repeatable stable builds
> (justin recommended it).
This is Maven 2.0.9 if I unde
Jody Garnett a écrit :
> I may propose another route - of bring GeoTools 2.6 to Java 6. Given our
> yearly release schedule I think I can get support for this. GeoServer
> will only be using GeoTools 2.6 for GeoServer 2.0; uDig is already using
> Java 6 on most platforms (and I am waiting word
Hello Jody
Jody Garnett a écrit :
> The reason
> we cannot have one big jar of geotools (tm) is more to do with the
> choice of FactorySPI as the plugin system than anything to do with maven.
This is not true. Geotidy build daily one big JAR with everything in it since
last summer. With Maven,
GeoTools 1 was using Ant if my memory serves me right. Ant could has been
considered an alternative to Maven. But the fact that Maven injects some
standardization (standard directories, standard build phase) was considered a
good point since it brings a bit of uniformity.
But above all, the maj
Hello Landon
Maven is difficult and unfortunatly not bug free. But I'm not aware of much
alternative... The goal was to allow developper to just invoke "mvn install"
from the root and get everything built, including dependencies.
Part of current difficulties is that our Maven configuration got
Hello Landon
If you stick to GeoAPI interfaces, there is no change. Both GeoTools and
Geotidy
implement the same set of interfaces. This also means that you can try a
library
and switch to the other without any change in your code.
If you use directly GeoTools implementation classes, most of
Jesse Eichar a écrit :
> I second that. Thanks for the update.
> On 4-Feb-09, at 12:46 AM, Michael Bedward wrote:
>
>> Many thanks for this and the other updates Martin
My pleasure :). I was unsure if it was of interrest or not.
Martin
-
To keep peoples informed:
All map GT2 projections are working, plus a few new projections (including
support on ellipse for projections that were previously supported only on
sphere). WKT parsing and formatting do not confuse anymore the various
parameter
names used by different authorities (O
Andrea Aime a écrit :
> I personally would be ok with adding a "any later version", but I
> would feel more comfortable with just switching explicitly to v3
> (provided v3 does not have other significant changes I'm not aware
> of, haven't really read it, just read articles talking about it).
I co
Adrian Custer a écrit :
> Apache 2.0 is incompatible with the GPL v2.0. Indeed, a major motivation
> of GPLv3.0 was to allow the integration of Apache and GNU code. GPLv3 is
> compatible with Apache 2.0. Unfortunately, I don't remember any of the
> details so I don't know how this affects the LGPL
Adrian Custer a écrit :
>> I have found jai_imageio-1.1.jar and jai_codec-1.1.3.jar in the
>> geotools-2.5.2-bin.zip.
>> Therefore it seems that they are distributed and this could represent
>> the same problem involved in distributing our libs.
>
> Sounds like you have found a possible legal iss
web a écrit :
> The definition are stored in this package, at:
> org\geotools\referencing\factory\epsg\EPSG.sql
>
> But this file do not contain any definition for projection epsg:3785 (or
> older named 900913).
>
> Does anyone has done those entries in this file? Or are those entries
> somewhere
Hello Andrea
Andrea Aime a écrit :
> - when the soft reference gets enqueued, is the
>referenced value still available
According package javadoc, no. The javadoc said "Soft and weak references are
automatically cleared by the collector before being added to the queues with
which they are regi
Jan Jezek a écrit :
> AFAIK there are more similar methods that works mostly in the same way but
> the format of grid shift files is different
> (For example one of similar method is NTv2).
Yes, this is exactly the reason why it is taking me a little bit long to port
the NADCON transform from G
Hello Jan
Jan Jezek a écrit :
> does this mean that GeoTools epsg modules are no able to choose grid based
> method (if they are available in EPSG) instead of Bursa Wolf? If so then I'm
> looking forward to test that.
You are right. Up to date, the EPSG modules was never using the NADCON grids
Hello Frank
Frank Warmerdam a écrit :
> It has always been my understanding that the NADCON data files are
> in the public domain. The PROJ.4 project operates on this assumption.
> I don't believe there is a credit requirement, though it would of course
> be good manners.
Thanks a lot for sharin
Hello Vincent
Vincent Frison a écrit :
> Je viens de recevoir ce mail 1,5 an après mon bug report sur la ML dev de
> geotools.. plutôt bizarre! Sans doute une bizarrerie de Nabble..
Sometime SourceForge seems to send again emails a long time after they were
initially posted. But in this case, 1
I downloaded the NADCON grid files from http://www.ngs.noaa.gov/PC_PROD/NADCON/
and I'm considering to include them in the JAR file of GeoTools referencing
module, as an optional plugin. If I'm understanding right, it is in the public
domain because it is U.S. government work, so I would be allo
Andrea Aime a écrit :
> The whole thing uses the getServiceProviderByClass(Class)
> method, which returns the one and only factory instance
> registered for a certain factory class...
I can confirm that GeoTools FactoryRegistry requires a different class for each
factory. Actually this is the wa
Thanks a lot Adrian for all those explanation. I take this opportunit for
strething my plan about the port of geotidy to Java 5:
* Create a Mercurial clone of the Java 6 code repository.
* Use some automatic tools that remove all annotations on that clone,
not just JAXB ones. For example @Overr
Jan Jezek a écrit :
> epsg-hsql (GoeTools 2.6) gives AXIS["Southing", SOUTH], AXIS["Westing",
> WEST]
> epsk-wkt ( GoeTools 2.6) gives AXIS["x", EAST], AXIS["y", NORTH],
> (I don't know why it differs)
epsg-hsql is right since it takes its information directly from a real EPSG
database, wh
Jan Jezek a écrit :
> You are almost right - but when using ESRI Krovak without the parameters
> like X_SCALE (etc..) it produces CRS with westing southing (!!) directions
> for projected axis.
> (Sorry - I did not express 100% right in my previous post about this).
Damn!! Thanks a lot for your
Graham Davis a écrit :
> I am using the value of 2 degrees with 10 points. Is there documentation
> anywhere that explains the variance of using higher/lower degrees with
> more/less points?
Not as fas as I know. The javadoc for the WarpTransform2D constructor gives the
minimal amount of points, b
Hello Christian
Christian Müller a écrit :
> Attached are 2 images, the first georeferenced in EPSG:4326, the second
> reprojected into EPSG:31287
> The reprojection was done with
> Operations.DEFAULT.resample(coverageEPSG4326, crsEPSG31287).
> The result is not what I want, I think I have to rec
Hello Jan
I'm glad to hear from you :) (I was actually hoping for your reply).
Jan Jezek a écrit :
> Good news :-) I know that Krovak is little bit bizzare.
> I don't know about other projections, but in Krovak X_Scale = -1 has same
> meaning as changing the AXIS parameter from EAST to WEST in G
1 - 100 of 1990 matches
Mail list logo
