Hi Peter,
Nice work!! I see that I just missed you on irc. I am jdeolive, ping me
the next time you are on and we can talk about any issues you are having
with the xml parser.
-Justin
Bolla Péter wrote:
> Hi,
>
>> Also. Do we have a module set up for you yet? I don't see on in the
>> repository
Hi,
> Also. Do we have a module set up for you yet? I don't see on in the
> repository but I notice that you have a wiki page. This should be enough
> to get you an unsupported module. If we did it might be easier for me to
> help out.
I've just committed the two modules, gpx and xml-gpx under th
Looks good; can you create a JIRA with your nice picture, and then apply
your patch. It would also be really good if you can create a test case
showing your F / A / B problem and the fact that your patch fixes it.
Jody
> Hi list,
>
> I have been spending all day to figure out where a bug in my
Hi list,
I have been spending all day to figure out where a bug in my feature cache
is coming from.
The bug is the cache does not return a small number of features that a
reference FeatureSource does return (I am using MemoryDataStore as a
reference). What the cache does is it enlarges a query to
Hi Peter,
I apologize for things being a bit unclear. Let me try to explain better.
So when the parser sees an element which has a type of xsd:datetime it
will load the XSDateTimeBinding to parse it. And yes, currently this
binding will parse the string into a Calendar object, and specifically
an
Hi Justin,
> Regardless... the parser is able to convert between the types it needs
> so its not always a problem if they dont line up perfectly.
I don't really understand this. The parser reads the xsd, and decides
what type it should return based on that. Isn't that the way? So if it
sees xsd
Hi Justin,
> Also. Do we have a module set up for you yet? I don't see on in the
> repository but I notice that you have a wiki page. This should be enough
> to get you an unsupported module. If we did it might be easier for me to
> help out.
No, I don't have the module set up yet. I don't know,
Hi Peter,
Indeed dates are a pain in xml and java and are a constant source of
problems so I feel your pain :). Here is the general strategy we have
come up when mappings dates from xml to java and back:
xsd:date -> java.sql.Date
xsd:time -> java.sql.Time
xsd:datetime -> java.sql.Timestamp
xsd:da
have xsd date, time, datetime bindings line up with agreed temporal bindings
Key: GEOT-1449
URL: http://jira.codehaus.org/browse/GEOT-1449
Project: GeoTools
Issue T
MosaicIndexBuilder writes wrong filenames in the .shp file
--
Key: GEOT-1448
URL: http://jira.codehaus.org/browse/GEOT-1448
Project: GeoTools
Issue Type: Bug
Components: gc co
Hi Peter,
I just submitted the fix for this issue so if you are running from svn
you can update and get the fix.
As for this log error... my guess is that the schema is not being
specified correctly to the parser so it cannot find the proper schema
elements as it parses. You can change this behav
On a related note you guys are invited to a BBQ at my place on Saturday,
I figure food is the only way to interrupt the code sprint.
Jody
> Register and make your travel plans now! On August 23rd, our hotel
> room blocks will be released, and we will no longer have discounted
> rooms availabl
SLPParser fails for some RasterSymbolizer tags, the solution is provided in the
description. please review and commit
--
Key: GEOT-1447
URL: http:
Hi Justin,
Earlier, when I generated the bindings, I have had to modify the XSD as
you suggested below. But now, as I filled the bindings, and tried to
test, I had to remove the ":gpx" after the "xmlns", because otherways it
didn't worked, told me that "Could not find declaration for: ...
Crea
Hi Justin,
I have some time again, to work on the gpx parser, and found a problem.
There is a date field (actually there are more of them,
type="{http://www.w3.org/2001/XMLSchema}dateTime";), which the jaxp
translated to XMLGregorianCalendar attributes. The problem is, that the
XML parser retur
BasixXYNode implementaion does not correspond to documentation
--
Key: GEOT-1446
URL: http://jira.codehaus.org/browse/GEOT-1446
Project: GeoTools
Issue Type: Bug
Affects Version
Ciao Simone,
I am curious if the ImageIO.write method combined with the geophysics
companion of the grid coverage could be used for extracting a byte[] object
from the grid coverage that would preserve data that may go beyond the limits
of a simple rendered image pixel value? The biggest probl
Rob Atkinson wrote:
ahh - this is serius issue in the specifications front...
I think the behaviour is correct.
The OGC specifies that the urn: referenced coordinate systems should
always be interpreted as Lon/lat order,
oops - i meant lat/lon - getting tripped up myself...
in conformance t
Justin Deoliveira a écrit :
> The problem that I am running into is that in GeoServer we use the hint
> the to switch the axis of 4326. However when a WFS request comes in with
> the srsName of:
>
> "urn:x-ogc:def:crs:EPSG:6.11.2:4326"
>
> The hint does not seem to apply and the coordinate system
ahh - this is serius issue in the specifications front...
I think the behaviour is correct.
The OGC specifies that the urn: referenced coordinate systems should
always be interpreted as Lon/lat order, in conformance to the EPSG
"definition" - though they dont also specify that it should be in
20 matches
Mail list logo
