[mapguide-internals] RFC60 finalization

[Walt Welton-Lair]

> Secondly, it think it is wrong to request the implementation of the new 
> stylization for such transparent feature addition.
> RFC60 works fine for our case, why should we implement something that 
> does not harm anything but what we do not need?

The way your code is designed - where it does the work of grabbing the colors inside the MdfModel project - WILL NOT WORK for enhanced stylization in which there are referenced symbol definitions.  It's not possible to load referenced symbols from the resource service from inside the MdfModel code.  This is not a minor defect.  It requires that a lot of your code be refactored.  I already explained the problem last March.  Here's the excerpt:

"With the new enhanced stylization (RFC 14) the layer definition can reference symbol definitions (in addition to inlining them).  The symbols, of course, define colors which need to be accounted for.  Accessing referenced symbol definitions requires the resource service - we need to get the symbol definition resource from the service.  The MdfModel project (where VectorLayerDefinition is stored) does not have access (nor want access) to the resource service.  So if you want to properly support the new enhanced stylization with your RFC (you should) then we'll probably have to move this ComputeUsedColors method somewhere else.  There's a method - MgMappingUtil::ComputeStylizationOffset - which does something analogous to ComputeUsedColors, so possibly we can add ComputeUsedColors to MgMappingUtil."

So even if you don't add code to actually parse colors for enhanced style layers, you need to keep the bigger picture in mind and design your new code so it will be easy to add this support.

All along that's the real reason why I wanted you to take a look at this.  So that you would come to realize that your current design doesn't fully work as is.


> Open source is more like: Who needs it should code it!

True, but it's not an excuse for not doing the right thing.  People can't just add anything they want without taking account the bigger picture.  That's my take on this.


Walt

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Friday, October 23, 2009 9:03 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 finalization

Hi all,

I looked into the RFC60 code again and added some more features to it 
e.g. finding label colors.

However, a redirection of referenced featureIds which would cause a FDO 
lookup seems prohibitive expensive in this context.
I would not like to add this into the code simply as it could increase 
delay tile computation a lot.
So the interesting test here are performance related. Simple unit-tests 
are not sufficient for this.
Creating complex test data to test performance issues is tedious and 
very badly motivated!!! (specification vs. implementation from same hand)

Secondly, it think it is wrong to request the implementation of the new 
stylization for such transparent feature addition.
RFC60 works fine for our case, why should we implement something that 
does not harm anything but what we do not need?
This is not thought along open source paradigms.  Open source is more 
like: Who needs it should code it!
So we should leave this open and the next person that has real test data 
which doesn't work can post a defect!
Very easy process!


RFC60 is not trivial at all but it solves a real problem in real maps.
To block the inclusion of RFC60 into the code base on those matters is 
simply wrong in open source terms as it keeps others from using a new 
working feature.
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals