[mapserver-dev] RE: 6.0 release plan - RFC45 - Consistent units in CLASS-> STYLE

Stephen Woodbridge woodbri at swoodbridge.com
Thu Mar 24 13:52:29 EDT 2011 

+1 for Havard to have doc commit access

On 3/24/2011 12:32 PM, Lime, Steve D (DNR) wrote:
> I suppose we should talk on mapserver-dev. ;-) I'm happy to nominate you for documentation
> commit access. We like to try to match commits with tickets if non-trivial. There is a documentation
> component in trac that Jeff owns that can be used for that.
>
> One thing to note is that Jeff and Mike Smith started or at least pondered staring an "examples"
> effort in Montreal. I could see some of your symbolization examples being very useful in that context
> too.
>
> I'll start with a +1 on granting Havard Tveite commit access for documentation.
>
> Steve
>
> -----Original Message-----
> From: Havard Tveite [mailto:havard.tveite at umb.no]
> Sent: Thursday, March 24, 2011 11:25 AM
> To: Lime, Steve D (DNR)
> Cc: thomas.bonfort at gmail.com
> Subject: Re: 6.0 release plan - RFC45 - Consistent units in CLASS->  STYLE
>
> Dear Steve,
>
> I would be happy to contribute on the documentation
> related to rendering for version 6.  I will, of course,
> have to consult you and Thomas in order to get
> clarifications on what intended behaviour is in some
> cases...
>
> How do we proceed?  My osgeo user name is havatv.
>
> I have no experience with committing (I have only
> used SVN to check out).  Is there any documentation
> that can help me avoid making big mistakes when
> committing?
> I have found a book, that I hope can help:
> http://svnbook.red-bean.com/en/1.4/svn-book.pdf
>
> Is it enough to issue the svn commit command with a
> descriptive message using --message?
>
> I have had a look at the documentation development
> guide (http://mapserver.org/development/documentation.html),
> which seems reasonably straight forward.
> I have also read RFC 7.1, and have no problems with that.
>
> Håvard
>
> On 3/24/2011 3:42 PM, Lime, Steve D (DNR) wrote:
>> We'd be happy to have more documentation committers...
>>
>> -----Original Message-----
>> From: thomas bonfort [mailto:thomas.bonfort at gmail.com]
>> Sent: Thursday, March 24, 2011 4:46 AM
>> To: Havard Tveite
>> Cc: Lime, Steve D (DNR)
>> Subject: Re: 6.0 release plan - RFC45 - Consistent units in CLASS->   STYLE
>>
>> Thanks Havard,
>> For the documentation changes, it would probably be easier if you
>> could commit directly into the mapserver documentation site. I seem to
>> recall that for docs commit access, it is sufficient to post a short
>> message to the -dev list stating which areas you want to work on, and
>> your osgeo userid.
>>
>> ps: good news for rfc45, I've just been on the phone with a customer
>> here in france who will probably be funding the anchorpoint stuff :)
>>
>> On Thu, Mar 24, 2011 at 10:22, Havard Tveite<havard.tveite at umb.no>   wrote:
>>> An updated examples.sym (just the explaining text has changed).
>>>
>>> Håvard
>>>
>>> On 3/24/2011 10:17 AM, Håvard Tveite wrote:
>>>>
>>>> Very nice!
>>>>
>>>> How can I help updating the documentation?
>>>>
>>>> Another thing:
>>>> I looked at the 6beta distribution and found that there
>>>> was a symbol directory.
>>>> I have updated the files in that directory to use the
>>>> Mapserver 6 mechanisms.  You will find the new files
>>>> attached.  I have also included two PNG files that show
>>>> the images produced by the previous map and symbol files
>>>> using Mapserver 5.2 (example-org.png) and my updated
>>>> files using 6beta3 (example.png).
>>>> I have only updated the existing examples, but could
>>>> add other (more advanced) examples if you like.
>>>>
>>>> Håvard
>>>>
>>>> On 3/23/2011 4:07 PM, thomas bonfort wrote:
>>>>>
>>>>> Havard,
>>>>> fixed in trunk, please confirm ;)
>>>>>
>>>>> thanks for testing!
>>>>>
>>>>> thomas
>>>>>
>>>>> On Tue, Mar 22, 2011 at 15:27, Havard Tveite<havard.tveite at umb.no>
>>>>> wrote:
>>>>>>
>>>>>> Dear Thomas and Steve,
>>>>>>
>>>>>> I have now tested quite a bit on 6beta2.
>>>>>> Many improvements!
>>>>>>
>>>>>> I have one big concern that I think needs to be addressed
>>>>>> for 6.0:
>>>>>>
>>>>>> Units in LAYER->      CLASS->      STYLE
>>>>>> ------------------------------
>>>>>> The units used for the different elements of the STYLE now
>>>>>> vary, and I think that will be very confusing to the users.
>>>>>> * WIDTH and SIZE specifies the width/height of the line/symbol
>>>>>>     as the number of pixels/map units at the scale
>>>>>>     1:SYMBOLSCALEDENOM.  I like this!
>>>>>> * GAP uses the same units (that is the gap in pixels/map units
>>>>>>     at the scale 1:SYMBOLSCALEDENOM).  I like this!
>>>>>> * PATTERN uses the WIDTH of the line as the unit, so to get
>>>>>>     the gap as the number of pixels/map units at the scale
>>>>>>     1:SYMBOLSCALEDENOM, you have to multiply the GAP value by
>>>>>>     the value of WIDTH.  I don't like this!
>>>>>> * OFFSET seems to use the same approach as PATTERN when
>>>>>>     "displacing" lines (units relative to line WIDTH).
>>>>>>     For point symbols, it seems to use the same approach as GAP
>>>>>>     (pixels/map units at the scale 1:SYMBOLSCALEDENOM).
>>>>>>
>>>>>> My opinion is that the unit used for all the length/width/size
>>>>>> measure elements (GAP, OFFSET, PATTERN, SIZE, WIDTH) of
>>>>>> CLASS->      STYLE should be the number of pixels/map units at the
>>>>>> scale 1:SYMBOLSCALEDENOM (as is currently the case for WIDTH,
>>>>>> SIZE and GAP).  This would mean that the units used for
>>>>>> PATTERN and OFFSET (for lines) would have to be changed.
>>>>>>
>>>>>>
>>>>>> Håvard
>>>>>>
>>>>>> On 11/18/2010 4:13 PM, thomas bonfort wrote:
>>>>>>>
>>>>>>> Havard,
>>>>>>>
>>>>>>> rfc45 isn't dead, but the priority now is getting 6.0 out of the door,
>>>>>>> so I wouldn't expect those features by then.
>>>>>>> Once 6.0 is out, getting those features in is a matter of time and/or
>>>>>>> will and/or funding.
>>>>>>>
>>>>>>> cheers,
>>>>>>> thomas
>>>>>>>
>>>>>>> On Tue, Nov 9, 2010 at 16:23, Havard Tveite<havard.tveite at umb.no>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Dear Steve and Thomas,
>>>>>>>>
>>>>>>>> I have been extremely busy this summer and autumn, so I
>>>>>>>> have not been able to follow Mapserver developments very
>>>>>>>> closely.  But when I heard about the release plan for 6.0,
>>>>>>>> I thought about RFC45.  There has been some interest
>>>>>>>> during the last years for some of the suggestions there,
>>>>>>>> and I still think that it includes some very good ideas
>>>>>>>> for quality improvements of Mapserver symbol rendering.
>>>>>>>> I have kept track of the progress on Cairo, so I don't know
>>>>>>>> if anything of this has been addressed there.
>>>>>>>>
>>>>>>>> Here are some examples:
>>>>>>>>
>>>>>>>> Stable origin for tile generation + polygon fill symbols:
>>>>>>>>      This would require that for instance the coordinate system
>>>>>>>>      origo be used instead of a local origo when placing tiles
>>>>>>>>
>>>>>>>> Angle options - there has been some demand for compass (the
>>>>>>>>      current vector? default).
>>>>>>>>
>>>>>>>> Possibility to specify symbol origin for precise placement
>>>>>>>>      of symbols.
>>>>>>>>
>>>>>>>> And more.
>>>>>>>>
>>>>>>>> Someone more familiar with the Mapserver code should perhaps
>>>>>>>> go through RFC45 again and check what can be achieved for 6.0.
>>>>>>>> I may have the time in a few weeks to help with specifications.
>>>>>>>>
>>>>>>>> Håvard Tveite
>>>>>>>>
>>>>>>>> On 11/9/2010 8:59 AM, thomas bonfort wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Nov 8, 2010 at 18:07, Lime, Steve D (DNR)
>>>>>>>>> <Steve.Lime at state.mn.us>          wrote:
>>>>>>>>>>
>>>>>>>>>> RFC-50: I think this is out for 6.0 unless those authors are still
>>>>>>>>>> around.
>>>>>>>>>
>>>>>>>>> yes definitely. I'd like to tackle that one some day, but haven't got
>>>>>>>>> the time in the near future
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> RFC-52: The changes I’d like to see are relatively minor (from a
>>>>>>>>>> coding
>>>>>>>>>> perspective) and are a return to a single getShape() method in
>>>>>>>>>> MapScript.
>>>>>>>>>> It
>>>>>>>>>> will break 5.6 scripts but is simpler in the long run. I don’t know
>>>>>>>>>> that
>>>>>>>>>> an
>>>>>>>>>> RFC is necessary but I will start a ticket and we can go from there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> RFC-54: I think Thomas just needs to merge?
>>>>>>>>>
>>>>>>>>> I'm planning to do this before the end of the month. It might slip a
>>>>>>>>> bit from the planned 15th november
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> RFC-58 – RFC-63: Are all basically complete, perhaps need docs
>>>>>>>>>> though.
>>>>>>>>>
>>>>>>>>> RFC58 (kml) still needs a bit of love before being ready
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> RFC-64: Needs feedback. This may push us back a week or two
>>>>>>>>>> depending
>>>>>>>>>> on
>>>>>>>>>> feedback. I think 6.0 is the right time to implement though given
>>>>>>>>>> the
>>>>>>>>>> types
>>>>>>>>>> of proposed changes. They are not candidates for minor releases.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks for pushing on this…
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Steve
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: mapserver-dev-bounces at lists.osgeo.org
>>>>>>>>>> [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Tamas
>>>>>>>>>> Szekeres
>>>>>>>>>> Sent: Saturday, November 06, 2010 6:12 PM
>>>>>>>>>> To: mapserver-dev at lists.osgeo.org
>>>>>>>>>> Subject: [mapserver-dev] 6.0 release plan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> In search of my memory (and my mails) the recent plan of the 6.0
>>>>>>>>>> release
>>>>>>>>>> has
>>>>>>>>>> been scheduled as follows:
>>>>>>>>>>
>>>>>>>>>> "Plan for a feature freeze on Nov 15th, with a little over 2 months
>>>>>>>>>> for
>>>>>>>>>> betas, aiming for final release between Jan 15th and 31st"
>>>>>>>>>>
>>>>>>>>>> How do we stand with the upcoming activities in the light of this?
>>>>>>>>>>
>>>>>>>>>> I can see the following RFCs may be affected or must be scheduled:
>>>>>>>>>>
>>>>>>>>>> RFC-50 (OpenGL)
>>>>>>>>>> RFC-52 (One-pass query processing), we wanted to do some rework as
>>>>>>>>>> far
>>>>>>>>>> as
>>>>>>>>>> I
>>>>>>>>>> remember.
>>>>>>>>>> RFC-54 (Rendering overhaul)
>>>>>>>>>> RFC-58 (KML output)
>>>>>>>>>> RFC-62 (Additional WFS GetFeature Output Formats)
>>>>>>>>>> RFC-63 (OpenLayers viewer)
>>>>>>>>>> RFC-64 (Expression parser overhaul)
>>>>>>>>>>
>>>>>>>>>> Do we have any other plan which will be covered with an RFC soon?
>>>>>>>>>> How
>>>>>>>>>> much
>>>>>>>>>> time the pending efforts will take to be implemented?
>>>>>>>>>> The 6.0 release plan document may also updated with some up to date
>>>>>>>>>> information if possible.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> Tamas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> --
>>>>>>>> Håvard Tveite
>>>>>>>> Department of Mathematical Sciences and Technology, UMB
>>>>>>>> Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
>>>>>>>> Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Håvard Tveite
>>>>>> Department of Mathematical Sciences and Technology, UMB
>>>>>> Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
>>>>>> Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/
>>>>>>
>>>>
>>>
>>> --
>>> Håvard Tveite
>>> Department of Mathematical Sciences and Technology, UMB
>>> Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
>>> Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/
>>>
>>
>
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

More information about the mapserver-dev mailing list