[Geomoose-users] GM3 identify items in SpatiaLite db?
TC Haddad
tchaddad at gmail.com
Mon Dec 10 15:32:58 PST 2018
Got it, thanks for the help!
After much flailing, it turned out to be an illegal field name buried deep
in the file (137 fields, and one name included a period, ugh). This meant
that the GML being returned was malformed, and GeoMoose couldn't even parse
it.
Once past that error, the hint about case sensitivity became relevant,
because as soon as the GML was parsable, it would not populate the template
until the case of the field names matched.
thanks again!
On Mon, Dec 10, 2018 at 12:35 PM Jim Klassen <klassen.js at gmail.com> wrote:
> GetFeatureInfo doesn't take any query parameters that are case sensitive,
> but it's response contains field names. GeoMoose cares about the case of
> those field names matching the template (in the mapbook) and any other
> place they are used. Different data sources to MapServer have different
> defaults for how they handle the case of field names.
>
> For example, in the mapbook (or GeoMoose remote template):
>
> {{ properties.pin }} is not the same as {{ properties.PIN }} and to work
> it must match the field name as it is returned by MapServer. If it
> doesn't, the field will be shown as "???".
>
>
> On 12/10/18 12:48 PM, TC Haddad wrote:
>
>
> Thanks - I'll experiment a bit more. Case doesn't seem to be having an
> impact.
>
> What's confusing is that the GetFeatureInfo request doesn't use anything
> that would be case-sensitive, and my map file is set to return all fields,
> regardless of field name.
>
>
> On Mon, Dec 10, 2018 at 9:45 AM James Klassen <klassen.js at gmail.com>
> wrote:
>
>> I tried changing the demo parcels layer to GeoPackage with ogr2ogr and it
>> worked for me.
>>
>> I also I tried SpatiaLite, but identify returned ???? for all the
>> fields. I suspect this is a case issue, but I didn't have time to check
>> if changing the case in template would fix it.
>>
>> SpatiaLite might be case insensitive itself but it does present a case to
>> MapServer and then MapServer passes that onto GeoMoose. MapServer and
>> GeoMoose are both case sensitive.
>>
>> On Mon, Dec 10, 2018, 11:36 TC Haddad <tchaddad at gmail.com wrote:
>>
>>>
>>> Thanks, I think I am ok on the GM includes, but will play with the field
>>> name case. Everything I've seen says SQLite/SpatiaLite is
>>> case-insensitive...
>>>
>>> The GetFeatureInfo response is showing some sort of return, but it is
>>> not intelligible.
>>>
>>> Other things I've tried:
>>>
>>> - identifying the same data in GeoPacakge (identify fails in the same
>>> way), and
>>> - ESRI PGDB (identify succeeds, which is frustrating!)
>>>
>>>
>>>
>>> On Mon, Dec 10, 2018 at 9:12 AM James Klassen <klassen.js at gmail.com>
>>> wrote:
>>>
>>>> One thing to check is if the case of the properties. Different formats
>>>> have different conventions about lower/mixed/uppercase for the
>>>> properties/field names.
>>>>
>>>> If you look at the response to the GetFeatureInfo request is it showing
>>>> data?
>>>>
>>>> Another thing if you aren't using the standard GeoMoose includes, you
>>>> might be missing the metadata block to enable all the WMS/WFS request types.
>>>>
>>>> On Mon, Dec 10, 2018 at 8:49 AM TC Haddad <tchaddad at gmail.com> wrote:
>>>>
>>>>>
>>>>> Does anyone have a successful GM3 example of enabling Identify on
>>>>> items in a SpatiaLite db?
>>>>>
>>>>> I have a working example in GM2 that I am trying to transfer to GM3,
>>>>> and everything I've tried is failing.
>>>>>
>>>>> The layer draws just fine, and there are no significant error
>>>>> messages, just no results.
>>>>>
>>>>> Layer def and Mapbook snippet below, SpatiaLite db was created in QGIS
>>>>> 2.18.
>>>>>
>>>>>
>>>>>
>>>>> ---------------- fwd ---------------- >>
>>>>>
>>>>> LAYER
>>>>> NAME 'points'
>>>>> CONNECTIONTYPE ogr
>>>>> CONNECTION "\data\points.sqlite"
>>>>> DATA "points"
>>>>> STATUS ON
>>>>> TYPE POINT
>>>>> PROJECTION
>>>>> 'init=epsg:3857'
>>>>> END
>>>>> METADATA
>>>>> 'ows_title' 'points'
>>>>> 'ows_include_items' 'all'
>>>>> 'gml_include_items' 'all'
>>>>> END
>>>>> LABELCACHE ON
>>>>> LABELITEM 'SERVICELOC'
>>>>> TEMPLATE 'foo.html'
>>>>> CLASS
>>>>> NAME "Service Locations"
>>>>> STYLE
>>>>> SYMBOL "square"
>>>>> SIZE 8.0
>>>>> OUTLINECOLOR 0 0 0
>>>>> COLOR 0 0 255
>>>>> END
>>>>> LABEL
>>>>> TYPE TRUETYPE
>>>>> FONT vera_sans
>>>>> SIZE 8
>>>>> ANTIALIAS TRUE
>>>>> WRAP ' '
>>>>> COLOR 0 0 255
>>>>> OUTLINECOLOR 255 255 255
>>>>> BUFFER 4
>>>>> MINFEATURESIZE auto
>>>>> PARTIALS FALSE
>>>>> POSITION uc
>>>>> END
>>>>> END
>>>>> TOLERANCE 30
>>>>> END
>>>>>
>>>>> ++++++++++++++++++++
>>>>>
>>>>> <map-source name="points" type="mapserver">
>>>>> <file>points.map</file>
>>>>> <layer name="points" status="off">
>>>>> <template name="identify"><![CDATA[
>>>>> <div>
>>>>> <div style="background-color:Gainsboro">
>>>>> <b>Points</b>
>>>>> </div>
>>>>> <div class="item">
>>>>> <label>Location Number:</label> {{
>>>>> properties.LocNumber }}
>>>>> </div>
>>>>> <div class="item">
>>>>> <label>Location Street:</label> {{
>>>>> properties.LocStreet }}
>>>>> </div>
>>>>>
>>>>> </div>
>>>>> ]]></template>
>>>>> </layer>
>>>>> <param name="FORMAT" value="image/png;bits=8"/>
>>>>> </map-source>
>>>>>
>>>>> _______________________________________________
>>>>> Geomoose-users mailing list
>>>>> Geomoose-users at lists.osgeo.org
>>>>> https://lists.osgeo.org/mailman/listinfo/geomoose-users
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20181210/ee06e1ff/attachment.html>
More information about the Geomoose-users
mailing list