Andrea Aime wrote:
>>> Cool. Let's try to come up with perhaps a specific roadmap / pitch
>>> to put on the GeoServer site, so we can point people at a plan, that
>>> they can help accelerate with funding. I'll try to put some time in
>>> to this next week, perhaps we can try to pass it around
See http://hudson.opengeo.org/hudson/job/geoserver-trunk/611/changes
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prize
Andrea Aime ha scritto:
> Rob Atkinson ha scritto:
>> The original type is totally meaningless _unless_ its known to the
>> client, so being able to meet a known schema is a useful role of XSLT.
>
> Sorry, but given that the client cannot do any meaningful filter
> because the actual schema is not
Rob Atkinson ha scritto:
> The original type is totally meaningless _unless_ its known to the
> client, so being able to meet a known schema is a useful role of XSLT.
Sorry, but given that the client cannot do any meaningful filter
because the actual schema is not the one in which the
features are
See http://hudson.opengeo.org/hudson/job/geoserver-trunk/610/changes
Changes:
[groldan] fixed wfsv parent version and dependency over wfs instead of wfs11
which does not exist on trunk
--
[...truncated 3332 lines...]
[INFO] [install:install]
[INFO] Instal
Attempting to validate GetFeature results with xsd Parser fails
---
Key: GEOS-2454
URL: http://jira.codehaus.org/browse/GEOS-2454
Project: GeoServer
Issue Type: Bug
Compon
Rob Atkinson ha scritto:
> I'm all in favour of supporting XSLT, but not as an "outputFormat" -
> rather as a configurable per-layer per-output format option.
In my mind I was figuring out two ouptut formats, XSLT-GML2, XSLT-GML3,
that would generate GML2 or GML3 respectively and apply a trasforma
I'm all in favour of supporting XSLT, but not as an "outputFormat" -
rather as a configurable per-layer per-output format option.
XSLT would be fantastic as a stopgap to fix things or support encoding
options we want to play with but not code against, or to handle
complexity we cant efficiently ha
Thanks Arne, for all your work on the corrupted tiles.It's a very rare
situation so yes, it could be a fluke. We will check for choking Java processes
that may cuase the tiles to get corrupted.Thanks!EJ
_
Access your email online an
BBOX filter does not work on ArcSDE
---
Key: GEOS-2453
URL: http://jira.codehaus.org/browse/GEOS-2453
Project: GeoServer
Issue Type: Bug
Components: ArcSDE
Affects Versions: 1.7.0-beta1
Coverage Configuration edit/apply/save may lead to problems
---
Key: GEOS-2452
URL: http://jira.codehaus.org/browse/GEOS-2452
Project: GeoServer
Issue Type: Bug
Reporter: Si
Rob Atkinson ha scritto:
Cool. Let's try to come up with perhaps a specific roadmap / pitch to
put on the GeoServer site, so we can point people at a plan, that they can
help accelerate with funding. I'll try to put some time in to this next
week, perhaps we can try to pass it
>>> Cool. Let's try to come up with perhaps a specific roadmap / pitch to
>>> put on the GeoServer site, so we can point people at a plan, that they can
>>> help accelerate with funding. I'll try to put some time in to this next
>>> week, perhaps we can try to pass it around on a wiki site. I th
Simone Giannecchini ha scritto:
> Apart from this, I think it would be nice as well to have a pge where
> we can sketch ideas/problems/solutions/thoughts before going to the
> roadmap.
> I have set up a sample page here
> http://geoserver.org/display/GEOS/GeoServerEE+and+general+GeoServer+improv
Jody Garnett ha scritto:
...
>> Cool. Let's try to come up with perhaps a specific roadmap / pitch to
>> put on the GeoServer site, so we can point people at a plan, that they
>> can help accelerate with funding. I'll try to put some time in to
>> this next week, perhaps we can try to pass it
15 matches
Mail list logo
