On 20 May 2010 15:51, Jody Garnett wrote:
> We could have a "docs" folder in each module?
> - This would be good for user guide / module matrix information; and we
> could leave the "welcome" tutorials to the demo/example/docs folder
Not sure... Currently there are only two people (you and me) doi
On 20/05/2010, at 4:57 PM, Andrea Aime wrote:
> Eh, it might get tricky as we have two sources of uom specification,
> the literal itself, but also the symbolizer one. I guess the local
> one would win.
>
> Anyone interested in cooking up a patch?
Pick me pick me! After all I failed at applying
On 20/05/2010, at 5:00 PM, Michael Bedward wrote:
> On 20 May 2010 15:51, Jody Garnett wrote:
>> We could have a "docs" folder in each module?
>> - This would be good for user guide / module matrix information; and we
>> could leave the "welcome" tutorials to the demo/example/docs folder
>
> Not
On 20/05/2010, at 4:53 PM, Michael Bedward wrote:
> Hi Jody,
>
>> There is something you may of missed in the spec...
>>
>> See where it returns se:Function? That mandates that a "fallback" value is
>> provided; I
>> think that the fallback value may be used in cases where lookup value is not
Hi Jody,
> How about we do better then that; and write up a proposal. In order for the
> proposal to go
> ahead though we are going to have to ask for some help. We have gotten by
> with the initial
> idea from Justin - but we are going to need a bit more help setting up Sphinx
> and make files
Michael Bedward ha scritto:
> Hi folks,
>
> I'm looking at getting the Recode function working but, as usual, the
> symbology encoding specs are quiet about some of the fiddly bits...
> It's basically just a table lookup.
>
> Questions: What do we return if the lookup value isn't found ?
So re
Jody Garnett ha scritto:
> On 20/05/2010, at 4:57 PM, Andrea Aime wrote:
>
>> Eh, it might get tricky as we have two sources of uom
>> specification, the literal itself, but also the symbolizer one. I
>> guess the local one would win.
>>
>> Anyone interested in cooking up a patch?
>
> Pick me pi
Yes, let's make it null.
Michael
On 20 May 2010 17:17, Andrea Aime wrote:
>
> So recode acts like an hashamp right, it's a key/value transformation?
> I would say, we return null if the key is not known. Same contract
> as a java Map?
>
---
Automatic xlink:href encoding for simple features
-
Key: GEOT-3094
URL: http://jira.codehaus.org/browse/GEOT-3094
Project: GeoTools
Issue Type: New Feature
Components: core xml
Hi all,
Resurrecting this old thread. I've discussed this with Ben, who suggested to
add an option for the users to enable automatic xlink:href at their own risk
(of slowness). The issue has been raised here: GEOT-3094.
I think it's a good idea, as done for GEOT-3046. Should we go ahead and do
th
Rini Angreani ha scritto:
> Hi all,
>
> Resurrecting this old thread. I've discussed this with Ben, who suggested to
> add an option for the users to enable automatic xlink:href at their own risk
> (of slowness). The issue has been raised here: GEOT-3094.
> I think it's a good idea, as done for GE
Excellent. I'll make sure our developer tries to make this as memory
efficient as possible.
Otherwise we can display a message to warn users for the impact if it can't
be helped.
Cheers
Rini
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Encoding-GML-and-Xlink-tp4930
On 20/05/2010, at 5:32 PM, Andrea Aime wrote:
> Jody Garnett ha scritto:
>> On 20/05/2010, at 4:57 PM, Andrea Aime wrote:
>>> Eh, it might get tricky as we have two sources of uom
>>> specification, the literal itself, but also the symbolizer one. I
>>> guess the local one would win.
>>> Anyone i
Jody Garnett ha scritto:
>> Otherwise we have to scrap the rescaling visitor and rebuild the
>> uom -> px logic all in the SLDStyleFactory and also kiss goodbye
>> the ability to automatically figure out the rendering meta-buffer
>> when doing queries.
>>
>> So... what about having the rescale
Hi all,
we are doing a project in Finnish meteorological institute and trying
to use Geotools library ( xml and wms extensions ) for our benefit.
At the moment we are parsing WMS getCapabilities responses with
Geotools-library, but can't seem to be able to make the parser to use
local schemas, ra
DuplicatingStyleVisitor ignores that Geometry can be any Expression and only
copies simple Property-Expressions
---
Key: GEOT-3096
URL: http://jira.codehau
We were just talking with Ben about how to make our parsers use schemas
provided as jar files - I don't quite understand his technique yet but I am
hopeful it can be adapted for wider use in the library.
The WMS parser code is basically "geotools parser 3" and is not the most
flexible or easier
On 20/05/2010, at 6:42 PM, Andrea Aime wrote:
>> So at the end of the day we want the rescaling visitor to do
>> everything it can prior to letting the renderer at it. Question. Can
>> the rescale visitor inject a function expression around entries in
>> order to accomplish a conversion?
>
> Why a
Hi,
for the Geomajas project, a proposal has just been made to create an
image pyramid plug-in so that the Geomajas server can directly use
georeferenced image layers. This proposal has not been based on the
GeoTools image pyramid plug-in, even though Geomajas is built upon
GeoTools. The reaso
Recode function as per SE 1.1 spec
--
Key: GEOT-3097
URL: http://jira.codehaus.org/browse/GEOT-3097
Project: GeoTools
Issue Type: Improvement
Components: core render
Reporter: Michael Bed
On Thu, May 20, 2010 at 12:32 PM, Jody Garnett wrote:
> We were just talking with Ben about how to make our parsers use schemas
> provided as jar files - I don't quite understand his technique yet but I am
> hopeful it can be adapted for wider use in the library.
Great, and thanks for the swift
> I was reading discussions on the mailinglist and got the impression
> that there was something on the todo list related to this.
>
> I'm now going to ask some elementary and/or stupid questions to
> understand how the parsing currently works, since as I looked into the
> testcase and ran it - it
I am not sure I get it what are we trying to do with this change?
On 20/05/2010, at 9:40 PM, Heimo Laukkanen wrote:
> As a sidenote to the WMS module, could someone make following fix to
> the Extent class, unless it breaks something else.
>
> public class Extent extends org.geotools.data.wms.xm
On Thu, May 20, 2010 at 4:07 PM, Jody Garnett wrote:
> I am not sure I get it what are we trying to do with this change?
Well at the moment, when you parse getCapabilities responses and have
layers with dimensions and dimension extents, for example:
hydro.runoffmaxaverage
Average maximum runoff
There are 2 plugins handling pyramids
1) pyramid plugin, handling pyramids read from files
2) imagemosaic-jdbc plugin handling pyramids reading from a jdbc database.
I am the module maintainer of the second and there are many db
different layouts for handling pyramids. As an example, Oracle
G
In adopting Sphinx for the GeoTools docs you may find breathe useful:
http://github.com/michaeljones/breathe
It adds markup directives to Sphinx to reference specific
classes/methods/packages as marked-up by doxygen (which is in turn
compatible with all the standard Javadoc markup. Not sure ab
For your information only.
A customer denoted an IBM p4 series machine to me, which is a power pc
architecture.
I succeeded installing Debian 64 bit and all the needed development
stuff. Interestingly, there is an open-jdk 1.6 available beyond the
ibm sdks.
I checked out geotools/geoserver
On 21 May 2010 00:46, David Winslow wrote:
> In adopting Sphinx for the GeoTools docs you may find breathe useful:
> http://github.com/michaeljones/breathe
>
Yes, that does look like it might be useful David. I haven't used
doxygen since renouncing C++ (last millenium) but if it's compatible
with
Been having some issues with people following the quickstart ...
Running:
mvn exec:java -Dexec.mainClass="org.geotools.demo.example.App
Getting:
The plugin 'org.apache.maven.plugins:maven-exec-plugin' does not exist
or no valid version could be found
I am unsure if they have the following from
Hi Jody
> Running:
> mvn exec:java -Dexec.mainClass="org.geotools.demo.example.App
>
> Getting:
>
> The plugin 'org.apache.maven.plugins:maven-exec-plugin' does not exist
> or no valid version could be found
Weird. You shouldn't need any reference to the exec plugin in the
project pom (just teste
Okay let me try again ...
gt-wms
==
org.geotools.data.wms.xml.Extent
-this is a class it does not implement any interfaces
- the isEmpty fix is applied here :-)
- this is the end of the line no modules depend on wms so nothing can extent
org.geotools.data.wms.xml.Extent
- this class could im
On 20/05/2010, at 11:47 PM, Heimo Laukkanen wrote:
> On Thu, May 20, 2010 at 4:07 PM, Jody Garnett wrote:
>> I am not sure I get it what are we trying to do with this change?
>
> There isn't a way to get the data ( extent ) from the dimension.
Okay we have two many things called extent - we bet
>> The plugin 'org.apache.maven.plugins:maven-exec-plugin' does not exist
>> or no valid version could be found
>
> Weird. You shouldn't need any reference to the exec plugin in the
> project pom (just tested this to make sure).
Then why do we have one in demo/example :-)
I think perhaps it is h
>> The plugin 'org.apache.maven.plugins:maven-exec-plugin' does not exist
>> or no valid version could be found
>
> Weird. You shouldn't need any reference to the exec plugin in the
> project pom (just tested this to make sure).
Then why do we have one in demo/example :-)
I think perhaps it is h
On 21 May 2010 13:02, Jody Garnett wrote:
>> Weird. You shouldn't need any reference to the exec plugin in the
>> project pom (just tested this to make sure).
>
> Then why do we have one in demo/example :-)
Because it's always been there ?
I'll try hiding my repository and then building and runni
Hi Jody,
I hid my local repo then built the quickstart with the pom as per the
web page (which contains no reference to the maven exec plugin). Maven
downloaded the internet then built the program without any errors.
Then I ran it with:
mvn exec:java -Dexec.mainClass="foo.bar.Quickstart"
The exe
I thought there were two repositories; one for build plugins (such as exec) and
another for the artifacts ...
Thus far the user I was helping solved there problem by including the pom.xml
lines mentioned earlier.
Jody
On 21/05/2010, at 3:17 PM, Michael Bedward wrote:
> Hi Jody,
>
> I hid my
> I thought there were two repositories; one for build plugins (such as exec)
> and another for the artifacts ...
Mmm... not unless maven uses a different structure on some platforms
(?) The exec plugin should be in org/codehaus/mojo within your normal
~/.m2 repository.
> Thus far the user I wa
I am ccing the developer in on the conversation so you can ask him questions
directly.
On 21/05/2010, at 3:30 PM, Michael Bedward wrote:
>> I thought there were two repositories; one for build plugins (such as exec)
>> and another for the artifacts ...
>
> Mmm... not unless maven uses a differ
On 21 May 2010 15:41, Jody Garnett wrote:
> I am ccing the developer in on the conversation so you can ask him questions
> directly.
Right...
So why are you causing all this trouble Scott ? :-)
--
Scott, Jody,
I found a few discussions where people had the same prob finding the
exec plugin but got it to work by using the fully qualified plugin
name the first time...
mvn org.codehaus.mojo:exec-maven-plugin:java
-Dexec.mainClass=org.geotools.Quickstart
No idea why it happens.
Michael
RasterToVectorFactory OUTSIDE parameter has wrong type
--
Key: GEOT-3098
URL: http://jira.codehaus.org/browse/GEOT-3098
Project: GeoTools
Issue Type: Bug
Affects Versions: 2.6.0
42 matches
Mail list logo
