[mapserver-dev] Request for review/comments on RFC 85 (Contour Layer Rendering)

Tue Mar 26 11:20:36 PDT 2013

Daniel (and Alan),

   Sounds good;  I know it can be a challenge to balance designing for 
the future and just getting things built.

Something for future consideration: contour labeling - blanking/clipping 
contour lines (but not other features) under the bound box of the 
contour labels.

Thanks for all your work!

Best Regards,
Brent Fraser

On 3/26/2013 11:46 AM, Daniel Morissette wrote:
> Hi Brent,
>
> We discussed this important question here with the rest of the team 
> and came to the conclusion that the current approach (CONNECTIONTYPE 
> CONTOUR + CONNECTION pointing to raster data file) could be extended 
> some day to support a reference to another layer of type RASTER as the 
> CONNECTION source (similar to the way a TILEINDEX can refer to a 
> separate layer as the tileindex source). Doing this would provide more 
> flexibility but would also require lots of work under the hood so that 
> is not likely to happen soon, but at least we know that we have a 
> future solution to this problem that would be consistent with the 
> current approach in the layer definition.
>
> And for the short term, if one has multiple DEM files to use as input 
> then they could be indexed using a GDAL VRT. Providing a GDAL VRT as 
> CONNECTION input to a contour layer is already supported by the 
> current implementation.
>
> Hopefully my explanation makes sense
>
> Daniel
>
> On 13-03-26 10:33 AM, Brent Fraser wrote:
>> Steve,
>>
>>    I'd rather not overload (pollute? erode? highjack?) the meaning of
>> existing object keywords. For example, "TYPE CONTOUR" would imply
>> contours could only be rendered as lines; the future we might want to
>> render them as polygons.
>>
>>    While not ideal, using the PROCESSING directive to specify the type
>> of processing doesn't step on the other keywords.
>>
>> Best Regards,
>> Brent Fraser
>>
>> On 3/26/2013 8:10 AM, Lime, Steve D (MNIT) wrote:
>>> It would be nice to avoid using the processing directive in this way.
>>> Why not simply use the layer TYPE or "TYPE CONTOUR".
>>>
>>> Steve
>>>
>>> ________________________________________
>>> From: mapserver-dev-bounces at lists.osgeo.org
>>> [mapserver-dev-bounces at lists.osgeo.org] on behalf of Brent Fraser
>>> [bfraser at geoanalytic.com]
>>> Sent: Tuesday, March 26, 2013 8:47 AM
>>> To: Alan Boudreault
>>> Cc: mapserver-dev at lists.osgeo.org
>>> Subject: Re: [mapserver-dev] Request for review/comments on RFC 85
>>> (Contour Layer Rendering)
>>>
>>> Instead of
>>>       CONNECTIONTYPE CONTOUR
>>>
>>> how about using
>>>       PROCESSING "TYPE=CONTOUR"
>>> or
>>>       PROCESSING "TYPE=DEM2CONTOUR"
>>>
>>> to allow the CONNECTIONTYPE to specify a connection to a database, etc
>>>
>>> Best Regards,
>>> Brent Fraser
>>>
>>> On 3/26/2013 6:21 AM, Alan Boudreault wrote:
>>>> Brent, yes, that's what I mean in my first point.. but typo. * the
>>>> connectiontype use will be kept*... until we define another way for
>>>> hybrid layers.
>>>>
>>>> Thanks
>>>> Alan
>>>>
>>>> On 13-03-25 10:07 PM, Brent Fraser wrote:
>>>>> So we're sticking with the "CONNECTIONTYPE CONTOUR"?
>>>>>
>>>>> Best Regards,
>>>>> Brent Fraser
>>>>>
>>>>> On 3/25/2013 1:22 PM, Alan Boudreault wrote:
>>>>>> Dev,
>>>>>>
>>>>>> I would like to do the inclusion this week. A few comments about the
>>>>>> current implementation:
>>>>>>
>>>>>> - For now, I think the contourlayer use will be kept, we will 
>>>>>> need to
>>>>>> think more about hybrid layers for mapserver 6.4.
>>>>>> - Tileindex are not supported (yet)
>>>>>> - Postgis raster are not supported (yet)
>>>>>>
>>>>>> http://mapserver.org/trunk/development/rfc/ms-rfc-85.html
>>>>>>
>>>>>> I'll do the call for vote tomorrow morning if there's no objection.
>>>>>>
>>>>>> Alan
>>>>>>
>>>>>> On 12-09-21 03:22 AM, Havard Tveite wrote:
>>>>>>> I am not sure if contour generation should be a job for Mapserver,
>>>>>>> but if we decide to implement it, I think there is a need for
>>>>>>> processing directives for "smoothing" / generalisation.
>>>>>>> It should be possible to specify the level of "smoothing" for the
>>>>>>> DEM as well as for the resulting contours.
>>>>>>> Smoothing levels could be specified as the maximum deviation
>>>>>>> allowed from the "original".
>>>>>>> Contour "smoothing" / generalisation needs to pay attention to
>>>>>>> neighbouring contours / topology, so that contours don't cross
>>>>>>> after smoothing.
>>>>>>>
>>>>>>> Possible processing directives for a DEM tolerance of 25 units
>>>>>>> (xyz) and contour tolerance of 10 units (xy):
>>>>>>> PROCESSING "DEM_TOLERANCE"=25"
>>>>>>> PROCESSING "CONTOUR_TOLERANCE=10"
>>>>>>> They could be made scale dependent in the way that is suggested
>>>>>>> in the RFC.
>>>>>>> "TOLERANCE" might not be the best word - "GENERALIZATION"
>>>>>>> is also be a possibility.
>>>>>>>
>>>>>>> It would also be good to choose an approach that will not
>>>>>>> make it impossible to use a point layer (xyz or xy+height
>>>>>>> attribute) as a data source.
>>>>>>>
>>>>>>> Håvard
>>>>>>>
>>>>>>> On 9/20/2012 5:40 PM, Alan Boudreault wrote:
>>>>>>>> Hi devs,
>>>>>>>>
>>>>>>>> I'd like to request some review on a pending RFC regarding support
>>>>>>>> for
>>>>>>>> contour layer rendering.
>>>>>>>>
>>>>>>>> Please see
>>>>>>>> https://raw.github.com/mapserver/docs/master/en/development/rfc/ms-rfc-85.txt 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The official rfc page should be updated in about a hour.
>>>>>>>>
>>>>>>>> http://mapserver.org/trunk/development/rfc/ms-rfc-85.html.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alan
>>>>>>> _______________________________________________
>>>>>>> mapserver-dev mailing list
>>>>>>> mapserver-dev at lists.osgeo.org
>>>>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>