Well after forking some of Martins code (from referencing) Justin walked
me through the needed maven magic
Rather then explain here is the snip:
>
> org.geotools
> gt2-referencing
> ${project.version}
> test
>
>
>org.opengi
One thing I was wondering as I hunted down the FeatGeomFactoryImpl in
search of a CoordinateReferenceSystem is *why* DimensionModel would ever
of been made.
Well now I have an answer.
Those working on this library *never* had a real
CoordinateReferenceSystem object to work with. I know because
Well a friendly "update your geoapi snapshot with a -U" right after
committing a dependency on a new snapshot would help as well. Depending
on a particular snapshot sounds like a good idea though.
Cory Horner wrote:
> Justin Deoliveira wrote:
>> Run maven with the -U switch. YOU need to tell it
Justin Deoliveira wrote:
> Run maven with the -U switch. YOU need to tell it to pick up a new
> geoapi jar.
This sucks... why can't we make life difficult for the one developer who
is changing GeoAPI rather than *everyone* else? (ie, reference a
specific geoapi snapshot timestamp)
Saul you will find the code compiles now; still having fun with the
tests ...
Jody
> Hey all,
>
> No problems with the geoapi Precision update from my end.
>
> However I've got broken trunk in unsupported/geometry. Tests don't match the
> implementation:
>
> in WKTReader.java there's one constr
Run maven with the -U switch. YOU need to tell it to pick up a new
geoapi jar.
Farber, Saul (ENV) wrote:
> Hey all,
>
> No problems with the geoapi Precision update from my end.
>
> However I've got broken trunk in unsupported/geometry. Tests don't match the
> implementation:
>
> in WKTReade
I am working on that now (the official build is Java 1.4 based) - I can
commit code that compiles (but I have test failures).
For interest I found that the unsupported/geometry implementation is
built around some flaws
FeatGeomFactoryImpl - is a "container" that holds the following
- Coord
Hey all,
No problems with the geoapi Precision update from my end.
However I've got broken trunk in unsupported/geometry. Tests don't match the
implementation:
in WKTReader.java there's one constructor defined (with three args):
public WKTReader(PrimitiveFactory aPrimitiveFactory,
Jody Garnett wrote:
> - can we set up a mac specific profile that:
> - does the same thing as the "nojai" profile
> - turns off the modules that require odbc bridge
> - anything else required Tim?
I've tweaked the root pom and plugin pom:
- mac causes the nojai profile to be activated by default
-
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/84/buildId/174
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/173
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
Jody Garnett wrote:
>>[INFO] Compilation failure
>>
>>/home/cruise/continuum-1.0.3/apps/continuum/working-directory/1/modules/unsupported/jts-wrapper/src/main/java/org/geotools/geometry/jts/spatialschema/geometry/GeometryImpl.java:[28,42]
>> cannot resolve symbol
>>symbol : class Precision
>>loca
Hi Justin:
Here is the link to the build on your box:
-
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=167&id=1
And here is the failure:
> [INFO] Compilation failure
>
> /home/cruise/continuum-1.0.3/apps/continuum/working-directory/1/mo
I think I am good on this end - only tests I have failing are not
commited. In anycase I am not doing anything *else* until the build is
back.
Cheers,
Jody
Justin Deoliveira wrote:
> I updated the build box to update snapshots every time. Still no luck.
> Where are we on this. Build is still b
Thanks for all the background - I will see if I can cut and paste it to
the wiki. Agreed - until someone needs to extend it
we need not worry about the "dialects" thing - unless that person is
called Andrea and the extension is to support
FIDs :-)
Jody
> Well, cql is defined in "OGC Cataloge S
I updated the build box to update snapshots every time. Still no luck.
Where are we on this. Build is still broken.
Jody Garnett wrote:
> Checking the commits it comes down to http://jira.codehaus.org/browse/GEO-93
> Thanks for including the jira in the commit log Cory.
>
> It does look as getVe
table schema handling does not work
---
Key: GEOT-1208
URL: http://jira.codehaus.org/browse/GEOT-1208
Project: GeoTools
Issue Type: Bug
Components: data db2
Reporter: Christian Mueller
On Thu, 2007-03-22 at 11:46 +0100, Tim Robertson wrote:
> I'm sure I must have the wrong branch checked out
> (http://svn.geotools.org/geotools/trunk)
yeah, try http://svn.geotools.org/geotools/trunk/gt/
which should avoid a bunch of experimental directories.
--
Well, cql is defined in "OGC Cataloge Service Specification v1.1.1 and v
2.0.0 " (OGC 02-087r3 y OGC 04-021r3)
There are a "mandatory query language" what can be extended (optional
languages).
In version 1.1.1 (OGC 02-087r3) present three types of query language:
"
- A common, mandatory q
Tim Robertson ha scritto:
> Hi
>
> Thanks Andrea
>
> I tried "mvn:install -Pnojai -Dmaven.test.skip=true" but that didn't work.
> Is that what you mean?
Yes it should have downloaded the jai files from lists.refractions.net.
Just tried on my pc, wiped out jai from my maven repo, and run th
Allow Geotiff reader to handle tiffs without CRS information
Key: GEOT-1207
URL: http://jira.codehaus.org/browse/GEOT-1207
Project: GeoTools
Issue Type: Bug
Components: g
21 matches
Mail list logo