table is “sde”, which is
quite telling.
Thanks for looking into this.
- Phil
From: Tamas Szekeres [mailto:szeker...@gmail.com]
Sent: Wednesday, February 29, 2012 1:41 AM
To: Anzel, Phil - NRCS, Fort Collins, CO
Cc: mapserver-users@lists.osgeo.org
Subject: Re: [mapserver-users] OGR and MSSQL non
2012/2/28 Anzel, Phil - NRCS, Fort Collins, CO
> Hi, Tamas,
>
>
>
> I believe there is at least one bug in the OGR code: the SRID is not
> properly retrieved from the underlying Sql Server 2008 database or its
> value is ignored, and therefore zero records are returned.
>
>
>
Probably the geome
l.com]
Sent: Monday, February 27, 2012 2:59 PM
To: Anzel, Phil - NRCS, Fort Collins, CO
Cc: mapserver-users@lists.osgeo.org
Subject: Re: [mapserver-users] OGR and MSSQL non-specific error
2012/2/26 Anzel, Phil - NRCS, Fort Collins, CO
mailto:phil.an...@ftc.usda.gov>>
1. Note that I omitted th
2012/2/26 Anzel, Phil - NRCS, Fort Collins, CO
>
> 1. Note that I omitted the “tables=…” as it appears that naming a specific
> table would interfere with connection pooling if I’m using many layers
> drawing data from different tables. Do I understand the role of the
> “tables=…” incorrectly?***
incorrectly?
2. I added the explicit spatial filtering (STIntersects…). Is there a better
way to do this?
Thanks again,
- Phil
From: Tamas Szekeres [mailto:szeker...@gmail.com]
Sent: Sunday, February 26, 2012 12:25 PM
To: Anzel, Phil - NRCS, Fort Collins, CO
Cc: mapserver-users@lists.osgeo.org
Phil,
You should not specify the data section in the OGR layer definition unless
you would define and sql select statement preceding with the 'where'
keyword. The terms 'using unique' and 'using srid' are not meaningful for
the ogr driver these parameters are automatically retrieved from the
geome
