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.
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
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
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
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
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
>
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
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
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
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
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
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
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
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:
> 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
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:
> 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
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
18 matches
Mail list logo
