2009/4/1 Ben Caradoc-Davies :
> My problem is with 2.0.10, which does build GeoTools. I decided on a
> conservative upgrade to support -o with snapshots, and avoided 2.1.0;
> shortly after, this Andrea reported the problems with 2.1.0.
>
Sigh... I have to learn to get my 1s and 0s in the right ord
My problem is with 2.0.10, which does build GeoTools. I decided on a
conservative upgrade to support -o with snapshots, and avoided 2.1.0;
shortly after, this Andrea reported the problems with 2.1.0.
I am not sure if the platform encoding warning is cosmetic, or could be
a problem if I lose my
there's another thread on this Ben
http://n2.nabble.com/Maven-2.1.0-is-out%2C-and-won%27t-build-GeoTools-td2561750.html
Michael
2009/4/1 Ben Caradoc-Davies :
> I recently upgraded to Maven 2.0.10. When Building GeoTools I have
> noticed these warnings:
>
> [WARNING] Using platform encoding (Cp1
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 the default Windows code
page). Should I be
That's more than acceptable :-)
Thanks Jesse
Michael
2009/3/31 Jesse Eichar :
> I have a demo on friday morning so I can do this on friday. Is that
> acceptable?
>
> Jesse
--
___
[
http://jira.codehaus.org/browse/GEOT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Aime reopened GEOT-344:
--
Assignee: Andrea Aime
The issue is not resolved until the patches are commited to the Geotools trunk.
Provid
1)
Andrea, after the last messages I would propose:
Pass the resolution hint if you are sure that nothing bad can happen.
However you do it, I rely on getting the hint with feature types having one
geometry property with the same CRS.
2) I did a quick implementation of GeneralizingFeatureSourc
>>
>> The spec definitely does not prohibit it. But the CITE tests only
>> ensure we can handle multiple geoms in the same referencing system.
>
> Then I wonder why we have all this code around checking the JTS Geometry
> user data for a per-geometry CRS (in the rendering code in particular,
> i
Justin Deoliveira ha scritto:
>> - the same column can contain geometries with different spatial
>> reference system too. I know it sounds crazy, but as far as I remember
>> OGC WFS makes sure that you can handle that case as well... mixed
>> with the fact that in GeoServer you have to declar
> - the same column can contain geometries with different spatial
> reference system too. I know it sounds crazy, but as far as I remember
> OGC WFS makes sure that you can handle that case as well... mixed
> with the fact that in GeoServer you have to declare a SRS anyways
> (we have no w
coverageName is truncated when gdal plugin imports datasets having filenames
containing several dots.
-
Key: GEOT-2417
URL: http://jira.codehaus.org/browse/GEOT-24
Andrea Aime wrote:
> Hi,
> I'm testing out Maven 2.1.0 and it won't build GeoTools
> complaining the maven-build-config module has circular
> dependencies, in particular, it depends on itself.
> Which is true, as it inherits from a global pom
> that makes use of it.
>
> Generally speaking, wouldn'
Apologies to anyone who was holding their breath on this one; it's taken
me this long to look into the issue again. What I found was that GeoAPI
still wasn't updating with just a 'cd geotools; mvn install' so I
grabbed GeoAPI from svn and built a patch against that. I have updated
the ticket with
Christian Müller ha scritto:
> Andrea, I am not sure what you are meaning
> "same data source can provide different geometries properties"
> 1a)
> I assume you mean that within one feature type we can have more than one
> geometry property.
Indeed.
> Since a feature has a default geometry, this
On Tuesday 31 March 2009 14:38:32 you wrote:
Sorry. I forgot to reply to the devel list.
Indeed it was a problem with the JAVA_HOME variable.
Thanks to all.
> Hi,
>
> I had the same error when I built the javadoc for the trunk last week.
> It was due to a misconfiguration on my computer.
> For
Andrea, I am not sure what you are meaning
"same data source can provide different geometries properties"
1a)
I assume you mean that within one feature type we can have more than one
geometry property.
Since a feature has a default geometry, this is the one we should use. If I
have a feature
NaN values in PostGIS DataStore
---
Key: GEOT-2416
URL: http://jira.codehaus.org/browse/GEOT-2416
Project: GeoTools
Issue Type: Bug
Components: data jdbc
Affects Versions: 2.5.3
Environment:
Christian Müller ha scritto:
> But anyway, I do not want any generalization on the fly and 1) is my first
> target.
>
> Passing difference/offset in the native CRS as a hint would make me happy
> :-)
> If the hint is missing, you always get the base geometries, the same holds
> true if the val
Hi,
I had the same error when I built the javadoc for the trunk last week.
It was due to a misconfiguration on my computer.
For me, the problem was solved when I defined the JAVA_HOME environment
variable.
Regards,
Cédric
Simone Giannecchini a écrit :
> I think you are using java 1.6, you shou
I have a demo on friday morning so I can do this on friday. Is that
acceptable?
Jesse
On Tue, Mar 31, 2009 at 12:17 PM, Michael Bedward wrote:
> Hello,
>
> Any chance of getting this little one looked at soon ?
>
> http://jira.codehaus.org/browse/GEOT-2221
>
> cheers
> Michael
>
>
> --
Hello,
Any chance of getting this little one looked at soon ?
http://jira.codehaus.org/browse/GEOT-2221
cheers
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.
Justin has had the idea of breaking out geotools into seperatly
versioned modules; why not start with our maven build helpers:
- it is a good idea
- this is a sensible place to start
Jody
On Tue, Mar 31, 2009 at 7:15 PM, Andrea Aime wrote:
> Hi,
> I'm testing out Maven 2.1.0 and it won't build G
I think you are using java 1.6, you should use 1.5 to build.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob:+3
Hi all.
I have downloaded the 2.5.x branch from
http://svn.osgeo.org/geotools/branches/2.5.x and every time I try to build it
with "mvn install" it throws the following compilation failure:
[INFO]
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1482/changes
--
___
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists
old labels don't get cleared
Key: GEOT-2415
URL: http://jira.codehaus.org/browse/GEOT-2415
Project: GeoTools
Issue Type: Bug
Components: core render
Affects Versions: 2.5.4
Environment: Mic
Thanks for the information.
I never had the intension to generalise on the fly. I want to implement the
same principle I used
with the imagemosaic-jdbc module, storing pyramid levels in the datastore.
All the pre generalized geometries have to be valid, because WFS should also
be supported.
Hi,
I'm testing out Maven 2.1.0 and it won't build GeoTools
complaining the maven-build-config module has circular
dependencies, in particular, it depends on itself.
Which is true, as it inherits from a global pom
that makes use of it.
Generally speaking, wouldn't it be a good idea to keep
the mav
Christian Müller ha scritto:
> Last week I posed a question about having a FeatureSource which has also
> some generalizations of the vector data to speed up response time and reduce
> data transfer.
>
> While it is is surely not the problem to implement such a FeatureSource, I
> need the Sca
29 matches
Mail list logo
