Andrea, I applied the patch to 2.6.x and it works
About: {bbox}
We could create a JIRA issue (improvement)
About: geoserver integration.
Since I will use the virtual tables within a pregeneralized feature, I
create the virtual tables programmatically.
I think your headaches are caused by t
Christian Müller ha scritto:
> Yep, sounds good using {bbox}
> At the moment I have the problem with tons of views in my database. The
> virtual table concept could be a solution for this. If you like I would try
> to deploy virtual tables in Geoserver 2.x
> Is there anything preventing the patch
Yep, sounds good using {bbox}
At the moment I have the problem with tons of views in my database. The
virtual table concept could be a solution for this. If you like I would try
to deploy virtual tables in Geoserver 2.x
Is there anything preventing the patch to be applied to gt-2.6.x ?.
Is the
Christian Müller ha scritto:
> Hmm
> And how do you rewrite a query if the bbox param is missing ?
> e.g
> where st_area($bbox) > 10
> or
> where anAttr = aValue or
> or
> where anAttr = aValue and
> ?
That's why I enclosed the part with the bbox in { } and
said "We allow the user to add
Hmm
And how do you rewrite a query if the bbox param is missing ?
e.g
where st_area($bbox) > 10
or
where anAttr = aValue or
or
where anAttr = aValue and
?
Andrea Aime writes:
> Christian Müller ha scritto:
>> If I understand the concept, this feature will not add fu
Christian Müller ha scritto:
> If I understand the concept, this feature will not add functionality.
> The purpose is to make the statement more efficient
> right ?
Correct.
Though in fact in my mind it would make another class of usages
possible in practical terms (as opposed to possible in theo
If I understand the concept, this feature will not add functionality.
The purpose is to make the statement more efficient
right ?
Andrea Aime writes:
> Andrea Aime ha scritto:
>>> For example:
>>>
>>> SELECT id, name, url, ST_SetSRID(ST_Point(longitude, latitude),4326) as
>>> location FROM
Rob Atkinson ha scritto:
> This did occur to me - but I thought I'd stick with the first issue -
> can we dump sql-datastore and also have user-defined native sql
> procedures exposed as filter functions?
I did not look into the latter (exposing native sql procedures
as filter functions) but the j
Ben Caradoc-Davies ha scritto:
> On 19/03/10 22:22, Andrea Aime wrote:
>> during the NY OpenGeo code sprint last month we've designed
>> and coded support for what we call "virtual tables", that
>> is, feature types that are defined via a straight, native
>> sql query.
>
> Um, Andrea, did you just
This did occur to me - but I thought I'd stick with the first issue -
can we dump sql-datastore and also have user-defined native sql
procedures exposed as filter functions?
On Tue, Mar 23, 2010 at 12:53 PM, Ben Caradoc-Davies
wrote:
> On 19/03/10 22:22, Andrea Aime wrote:
>> during the NY OpenGe
On 19/03/10 22:22, Andrea Aime wrote:
> during the NY OpenGeo code sprint last month we've designed
> and coded support for what we call "virtual tables", that
> is, feature types that are defined via a straight, native
> sql query.
Um, Andrea, did you just invent a generic solution that supersede
On Tue, Mar 23, 2010 at 8:18 AM, Andrea Aime wrote:
> Rob Atkinson ha scritto:
>>
>> I see Gabriel is in the loop - this functionality sounds similar to
>> the sql-datastore module included in the 1.6 community-schemas
>> dependencies - can we get an analysis of how this new initiative
>> compares
Rob Atkinson ha scritto:
> I see Gabriel is in the loop - this functionality sounds similar to
> the sql-datastore module included in the 1.6 community-schemas
> dependencies - can we get an analysis of how this new initiative
> compares - and if its equivalent (or more complete) work with Ben to
>
I see Gabriel is in the loop - this functionality sounds similar to
the sql-datastore module included in the 1.6 community-schemas
dependencies - can we get an analysis of how this new initiative
compares - and if its equivalent (or more complete) work with Ben to
ensure we have some unit tests usi
This is a very good feature. IMHO, we should integrate it into trunk and 2.x
series a soon as possible.
Andrea Aime writes:
> Hi,
> during the NY OpenGeo code sprint last month we've designed
> and coded support for what we call "virtual tables", that
> is, feature types that are defined via
Ian Turton ha scritto:
> On Fri, Mar 19, 2010 at 10:22 AM, Andrea Aime wrote:
> [... lots of cool stuff ...]
>
> This sounds really cool Andrea, I'll see if I can test it out next
> week before marking kicks in. I really wish I had known that the Java
> tribe was going to the NY Sprint as I'd ha
On Fri, Mar 19, 2010 at 10:22 AM, Andrea Aime wrote:
[... lots of cool stuff ...]
This sounds really cool Andrea, I'll see if I can test it out next
week before marking kicks in. I really wish I had known that the Java
tribe was going to the NY Sprint as I'd have come over, however all
the publi
Hi,
during the NY OpenGeo code sprint last month we've designed
and coded support for what we call "virtual tables", that
is, feature types that are defined via a straight, native
sql query.
If you cannot wait to see the code there is a patch attached
to http://jira.codehaus.org/browse/GEOT-2123.
18 matches
Mail list logo