[prev in list] [next in list] [prev in thread] [next in thread]
List: mapserver-dev
Subject: Re: [mapserver-dev] numeric values in string columns
From: Yewondwossen Assefa <yassefa () dmsolutions ! ca>
Date: 2008-11-11 13:02:35
Message-ID: 4919826B.8020605 () dmsolutions ! ca
[Download RAW message or body]
Bart,
bartvde@osgis.nl wrote:
> Yeah it would be great to have this, but I am sure this is the kind of
> thing that requires funding. Anybody have an idea how much approximately?
>
I am not sure if you meant the addition of layer's attributes support
directly in Mapserver or the metadata approach. I am not really able to
comment in detail on the first approach at this point. The metadata
approach is more limited in scope and more strait forward (0.5/1day)
> Btw is Mapserver getting any OsGeo sponsorship money that could be applied
> to these kind of tasks?
>
I am pretty sure no.
> Best regards,
> Bart
>
>>
>>> -----Original Message-----
>>> From: mapserver-dev-bounces@lists.osgeo.org
>>> [mailto:mapserver-dev-bounces@lists.osgeo.org] On Behalf Of
>>> Yewondwossen Assefa
>>> Sent: Monday, November 10, 2008 9:14 AM
>>> To: Bart van den Eijnden (OSGIS)
>>> Cc: mapserver-dev@lists.osgeo.org; Daniel Morissette
>>> Subject: Re: [mapserver-dev] numeric values in string columns
>>>
>>>
>>> Daniel Morissette wrote:
>>>> bartvde@osgis.nl wrote:
>>>>> Hi list,
>>>>>
>>>>> we've got a dataset with road numbers, the column in ArcSDE is a
>>>>> character type. But the values can look like numbers (002 etc.) as
>>>>> well as strings (e.g. N329).
>>>>>
>>>>> Mapserver will fail in this case, seeing it will check the
>>> value for
>>>>> determining the type of column (mapogcfilter.c).
>>>>>
>>>>> Will this be easy to fix, or will it require that Mapserver stores
>>>>> column types internally?
>>>>>
>>>> I'll let Assefa answer about mapogcfilter.c specifically,
>>> but I think
>>>> it would be a good thing to maintain the original column type.
>>>>
>>>> I started working on support for column types in MapServer
>>> a few years
>>>> ago but never finished it... I think that may even have
>>> been for WFS...
>>>> I checked this morning and unfortunately I could not find that code
>>>> anywhere.
>>>>
>>>> Daniel
>>>
>>>
>>> Ideally if the layer's column type is available with the
>>> layer object, we could use that. Not sure when/if that will
>>> be available.
>>> The other alternative is to use metadata on the layer (the
>>> same way we use it now for attribute name aliases). We could
>>> have <item_name>_type and have that value used to build the
>>> expressions. I am willing to add the metatadata support if
>>> you think this is appropriate.
>>>
>> This would also be useful for WFS DescribeFeatureType output, as the
>> schema response can map to the actual datatypes (and output, say,
>> xs:integer, xs:datetime, etc.) if specified.
>>
>> ..Tom
>>
>>
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst
Email: assefa@dmsolutions.ca
http://www.dmsolutions.ca/
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
_______________________________________________
mapserver-dev mailing list
mapserver-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic