[Geoprisma-users] Back to GP again

[Stephen Woodbridge]

Alexandre Dube wrote:
> Stephen Woodbridge wrote:
>> Alexandre,
>>
>> The new doc is a great improvement!
>>
>> Here are some random comments:
>>
>> 1) Looking at the Widget list 
>> http://geoprisma.org/dist/naturaldoc/files2/featurepanel/form/Form-txt.html 
>>
>>
>> I think it would be very helpful to standardize Widget names a little 
>> bit with the client project. This is already done for some of the 
>> MapFish widgets:
>>
    [snip widget list]
>>
>> Why bother you might ask? :)
>> Maybe this is not the way to do it, but you already started with this 
>> naming conventions and I think is has some value in making sensible 
>> widget choices. For example if I don't want to add in all the MapFish 
>> stuff then I can avoid using those widgets. I assume that over time 
>> and growth of the wisget library this will become more and more 
>> useful. Obviously there are other ways to do this and if you use the 
>> EditFeature tools then you are already commited to using the MapFish 
>> protocol which I assume means using some of there JS files?
>>
> 
> I agree that some "sorting" / "cleaning" work could be done.  It's kind 
> of a mess right now :)

This comment came out trying to understand what all the widgets do and 
how they are related or redundant. I'm assuming that at some point you 
will want to strip down the JS libs so you only need to install the 
minimum needed for your application to run to improve the load performance.

This will be critical as the widget list expands especially if more libs 
get pulled into the mix.

I'm guessing that right now you have to load all the required JS libs 
regardless of which widgets are used. Maybe this will always be the 
case? But then why for example are there two NavTools widgets today. If 
widgets "declared" their library dependencies, it would be easy to just 
include those libraries that were needed.

[more snipage]

>>
>> In general, the current doc is a little bit abstract, 
> 
> Yeah, I know...
> 
>> and would benefit from being a little more concrete. I would suggest 
>> defining a specific example for the Tutorial and referring to that 
>> example to explain each step, like:
>>
>> 1) a city wants to setup a GP service and has the following resouces:
>>
>> citylimits - polygon shapefile
>> lakes      - polygon shapefile with object names
>> parcels    - polygon shapefile with lots of attribute
>> streets    - line shapefile with moderate number of attributes
>>
>> The example data can be downloaded from HERE(link).
>>
>> The citylimits layer is a reference only layer
>> The lakes layer is also a reference only layer
>> The parcels layer is managed by the city tax department which needs to 
>> make sure it is updated as things change, but the public needs to be 
>> able to view it.
>> The streets layer is managed by the highway department which needs to 
>> mantain it, and add new streets as new subdivision are created. The 
>> public needs to view this as a reference layer also.
>>
>> 2) we have loaded all these layers into postgis database
>> 3) we have configured mapserver to serve WMS maps from the database
>>    - show a sample mapfile for the above
>> 4) we have featureserver installed
>>    - show a sample config file for the above
>>
> 
> I wouldn't go that far for the current tutorial.  It could be a nice 2nd 
> tutorial *for dummies*  What do you think ?

I think you need to assume that all newbies to your project will need 
the "tutorial for dummies" by definition of what a newbie is and hence 
the need for tutorials in the first place.

I think you are on a roll and should keep going, the tutorial can always 
be updated with more detail in "rev 2", but making it more concrete will 
make it much more useful. I know it is a LOT more work. From a priority 
point of view you have a lot of things that are not documented, a lot 
less than last week :), so keep going so everything has a first pass of 
docs.

Thanks again for all your hard work.

-Steve