Jan 14 05:33:08 * Now talking on #mapbuilder
* Topic for #mapbuilder is: Community Mapbuilder channel | files: mapbuilder.sf.net | docs: docs.codehaus.org/display/MAP | dev-meeting: every tuesday 1800UTC
* Topic for #mapbuilder set by stvn at Thu Dec 29 22:07:53 2005
linda____ yes peter
Cappelaere yeaaaa
peter37 thanks
Cappelaere ye sperter
Cappelaere yes Peter!
linda____ and I thought that was the French spelling of Peter 
CameronShorter Oooh, I'm so excited, we have a full meeting room.
Cappelaere Full house today!
CameronShorter Steven, are you with us?
peter37 i may not stay on-line too long, I won't have a lot to add to the topics under discussion, however I wanted to prove that I could join in for another time
CameronShorter ok
CameronShorter Lets start.
CameronShorter Does anyone want to add anything to the agenda sent out by email?
madair Mapserver foundation?
Cappelaere sounds good
Cappelaere let's go
CameronShorter ok, and if we get time we could discuss commercial support ideas.
Cappelaere could add doc status since Peter is with us
Cappelaere already on the list, Srry
CameronShorter Yes, Peter why don't you start since you will need to leave early.
peter37 It would be good to have steve on-line if we were to do that
CameronShorter ok, next topic: meeting times.
peter37 As far as I see it Steve is having a first cut at the web site and I am havig a first cut t the tuorial.
CameronShorter Is this timeslot ok with people?
peter37 shall we seewhere we get to by next week
CameronShorter ok
CameronShorter sounds good.
linda____ I cannot say that 100% will be able to make this, but with it being during the EST work day, Friday is the best
CameronShorter By the way http://mapbuilder.sf.net is down.
madair I think the docs restructuring should be done before 1.0 is released
peter37 I am basing my tutorial on 1.0
CameronShorter Mike, Patrice, Peter: are you ok with this timeslot?
peter37 I will often be able to make frisdays at this time
madair yes this fine in general. (I'm away in Germany next week though)
Cappelaere not the best but ok
CameronShorter Could people please email when you are not coming so that we don't wait for you.
Cappelaere k
peter37 sure
linda____ k
CameronShorter Next topic: 1.0 release:
CameronShorter I haven't got much time to devote to this release so it will need to be up to others to make it happen.
CameronShorter And call the shots.
Cappelaere name is fine
Cappelaere 1.0rc2
madair I started to have a look at the bugs last night, prioritized the ones I think should be fixed
CameronShorter Yes, I don't think we can call it 1.0 untill we have a release candidate without major bugs in it.
Cappelaere bugs to be addressed ar the curent ones necessary to pass the tests I have
Cappelaere so far I mean
Cappelaere they are in bugzilla
Cappelaere I just synchronized with current 1.0RC1 in SVN but I have not run the tests
Cappelaere I will do that and post the results
Cappelaere We could go thru the list and check what else we have
CameronShorter Patrice, I think that we need to identify a priority level of bugs and fix all those bugs greater than that level.
madair the list is getting too long to go through in this IRC I think
linda____ agreed
Cappelaere let's agree on level then
Cappelaere 6 sounds good
CameronShorter I like 6.
madair sounds good
madair 6 gets fixed
peter37 can I say that David Herbert has added a bug to the list that is a show stopper for us. We would be keen to have it fixed.
Cappelaere I will make sure I test for all bugs 6+
CameronShorter ok thanks.
Cappelaere set it as a 6
peter37 sure
Cappelaere if you can
CameronShorter Peter, if you have a bug that needs fixing, make the priority 6 or greater.
Cappelaere I volunteer to test and report when we pass
CameronShorter thanks Pat.
madair thanks
Cappelaere MIke, we need to talk more about proj...
CameronShorter Who wants to fix bugs?
Cappelaere not for 1.0 right?
madair I'm assigning myself to the ones I'm working on
CameronShorter proj is a feature and hence should not go into 1.0. 1.0 is only for bug fixes.
linda____ I'm a little late in adding a topic: Does anyone still have issues with SVN access which need to be addressed.
madair yes proj would just go in the trunk
Cappelaere ????
madair we have to remember that a bug fix has to applied in both trunk and the 1.0 branch
Cappelaere 1.0 trunk?
CameronShorter I have svn issues on windows, but we can discuss later.
Cappelaere I am confused
madair trunk + tags/mapbuilder_lib-1_0-rc1
madair maybe branching strategy is a good topic now
Cappelaere My question then is what is the state of SVN right now?
CameronShorter Yes, mike: Topic = branching.
Cappelaere Do we have a branch already?
madair yes there is the tags/mapbuilder_lib-1_0rc1
madair I suggesst renaming that to just ...1_0 (without the RC)
CameronShorter We need to create a new branch in SVN called 1.0 which we copy from tags/rc1
CameronShorter mike: yes.
* tomkralidis (n=tkralidi@CPE0010a4b4241c-CM000a739b3cd4.cpe.net.cable.rogers.com) has joined #mapbuilder
madair then generate the release build from that branch and add the RCx at that point
madair just to the dist file
CameronShorter Yes: so the svn steps would be:
madair then when we are ready for 1.1, create a new branch in tags for 1.1, etc.
CameronShorter cp tags/1.0rc1 branches/1_0
CameronShorter develop on 1._0
CameronShorter then
CameronShorter cp branches/1_0 tags/1.0rc2
CameronShorter Right?
* peter37 (n=Peter37@host86-132-242-214.range86-132.btcentralplus.com) has left #mapbuilder
madair I would just do tags/1.0 tags/1.1 and make a note of the revision number when we cut a release
CameronShorter Hi Tom, anything you wanted added to the emailed agenda, or anything in particular you were interested in?
Cappelaere Are you saying that we should see 2 folders under mapbuilder: mapbuilder1.0 and mapbuilder1.1
madair under tags (one directory level above trunk)
tomkralidis hi everyone. I'm mostly observing, but I did have a question about adding to demo/
CameronShorter Currently our root directory is scm/
madair but Cameron your way would work too, I'm just think that might bloat the repository
CameronShorter Under that we have trunk/ tags/ branches/
CameronShorter What I'm describing is the process suggested in the svn-book (I guess the best practice).
linda____ Patrice do you have the root defined to be svn+ssh://svn.codehaus.org/home/projects/mapbuilder/scm/trunk
linda____ or svn+ssh://svn.codehaus.org/home/projects/mapbuilder/scm/
linda____ if it is scm
Cappelaere I see
linda____ then you will see the other directories the other people are talking about in the SVN repo browser of eclipse
Cappelaere yeap
CameronShorter SVN bloat is not a major issue. Disk space is cheap, and SVN is optimised so that files for difference directories don't get downloaded twice.
madair It doesn't matter too much to me either way, but we should decide on one way and write that down
madair but we still have to fix bugs in the trunk as well as the release branches
CameronShorter yes Mike.
CameronShorter Which means that Linda is right, you should be checking out scm/ instead of scm/trunk
Cappelaere agree
Cappelaere and we should not have a mapbuilder-lib-1_0-rc1 if it is in the trunk
Cappelaere or rename that one to 1.1
CameronShorter Ok, I propose we create scm/branches/1_0 based on tags/1.0rc1 and all 1.0 development should happen in the branches/1_0 directory.
madair no trunk should just have trunk/mapbuilder
CameronShorter +1
madair +1
Cappelaere +1
CameronShorter Pat, mapbuilder-lib-1.0rc1 is stored in the tags directory. The tags directory is used only for tagging releases.
madair can we clean out the branches and tags directories? (except for the RC1 until the above happens)?
Cappelaere you mean archiving of a release?
CameronShorter branches is almost empty.
madair I guess keeping the tags dirs around may be useful
CameronShorter We should not clean out the tags/ direoctry because it is the only place where we can identify what was in our previous releases (unless we go back to CVS).
madair yes ok
CameronShorter Next topic: timeline for 1.0
CameronShorter Any suggestions since you guys are doing the work?
Cappelaere Who will do this?
madair I'm not going to be able to get much done next week so I'll need at least 2 weeks to fix the bugs I can do
Cappelaere we could shoot for RC2 mid Feb
CameronShorter Based on previous experience, we need at least 2 weeks for the release build process. (including testing)
Cappelaere or Feb 3
madair or earlier if possible
Cappelaere gives us 2 weeks + few days testing and packaging
CameronShorter Aim for 2 weeks until we freeze the build?
CameronShorter Mike is that your preference?
madair that sounds fine
CameronShorter Does anyone want to volunteer for the build making process?
madair you mean freeze branches/1.0 right?
CameronShorter Mike, yes.
madair Matt usually does that?
CameronShorter Yes, we can see if Matt wants to do it again.
madair in this stragtegy, tags/* are always frozen right?
CameronShorter Mike, yes.
Cappelaere and we shoul donly see branches/1.0 and branches/1.1
CameronShorter Pat, for the moment we should only see branches/1.0 and the 1.1 will be developed on the trunk.
madair yes but branches/ is also for riskier development
Cappelaere This is confusing
madair where the branch is created until that branch is safe to merge back to the trunk
Cappelaere got it
madair eg. dojo integration will likely break Mapbuilder for a while
Cappelaere so we should see branch/1.1
linda____ in that case we are to delete the branch once merged???
CameronShorter If you have time, I suggest you read the SVN book, section on branching.
Cappelaere
madair this allows other developers to continue development on the trunk
Cappelaere ok
CameronShorter There are 2 main uses for branching:
CameronShorter 1. For developer of a stable release (in our case 1.0)
CameronShorter 2. for tempory development of an unstable part of code. For this, the branch is eventually copied back to the trunk.
* tomkralidis has quit ("Leaving")
Cappelaere right
CameronShorter For case 1, the branch never gets copied back to the trunk.
CameronShorter (You apply patches to branch and trunk at the same time)
Cappelaere that's where I have an issue
linda____ yes that is a problem for fat fingers
Cappelaere trunk is 1.0rc1 and becoming 1.0rc2 when we fix existing bugs
CameronShorter no
madair trunk is now heading for 1.1
CameronShorter trunk is development of all the extra features you want which will eventually be branched and become branches/1.1
Cappelaere ok
CameronShorter branches/1.0 will be copied from the tags/1.0rc1 . (or to be pure, we should copy branchs/1.0 from the trunk from the version which was used to create rc1)
madair there must be a way to fix a bug in the branch, and then just apply a patch to the affected file in the trunk
CameronShorter Mike, yes, there is a "svn join" function which can be used to copy a patch from one branch to another.
CameronShorter "svn join" is the suggested way to apply patches to 2 branches.
madair I'm concerned too about release bug fixes - it will be very easy to miss that extra step
madair I'll look into svn join
Cappelaere that's why we need the test scripts
CameronShorter Mike, yes making sure bug fixes get into both builds is an issue.
CameronShorter Pat, yes.
Cappelaere I will take care of this until you guys get up to speed
Cappelaere or someone else takes over
CameronShorter By the way, the CVS bug tracker is very bad at tracking bugs in 2 branches. Confluence (which is on codehaus) allows you to have a bug open on one branch and fixed in another branch.
CameronShorter ok, thanks Pat.
Cappelaere My head is hurting!
Cappelaere next
CameronShorter If anyone hasn't got anything to do, or if we could find a keen student, then it would be great to copy all our bugs from CVS to Confluence.
Cappelaere backlog?
CameronShorter Do we want to walk through the bug list and determine what should be fixed in 1.0?
CameronShorter Or shall we do that in our own time?
Cappelaere we agree to do 6+
Cappelaere let's move on
CameronShorter ok
madair I don't have time to dothat now. I suggest each of us goes through and does that
Cappelaere yeap
CameronShorter Next topic: backlog:
CameronShorter Pat, would you like to drive this?
Cappelaere sure
Cappelaere we need to create a backlog page on wiki
Cappelaere and move parking lot items to backlog
Cappelaere items on backlog will be developed within 6 months
CameronShorter what is the criteria for moving to the backlog?
Cappelaere a vote
CameronShorter I thiink there are 2 parts to moving to the backlog:
linda____ wouldn't we want to have everything in confluence marked with the appropriate tags
CameronShorter 1. We need a sponsor - ie someone volunteering to do the work.
CameronShorter 2. The PMC is to agree that the feature is a good idea.
Cappelaere sounds good to me
CameronShorter Linda, that would be a good idea. Use the confluence bug tracking system. What holds me back is that all our bugs are currently on Sourceforge.
linda____ I will take the action item to see if there is a bulk xfer of the items
CameronShorter Which is why I'd love to copy all open bugs from Sourceforge to Confluence.
Cappelaere Linda: can you scrape it?
linda____ I was hoping to XML it out of and into
linda____ but scrapping did cross my mind as well
Cappelaere you ar ein charge
Cappelaere go for it
Cappelaere
linda____ I will investigate it and report back the level of effort involved
linda____ if it is easy ... you might hear DONE!
linda____
CameronShorter Ok, thanks linda. I looked at it before. There is an XML dump from sourcefoge bug tracker, but it produces invalid XML which would need to be cleaned up.
madair thanks linda
Cappelaere thanks linda
Cappelaere so back to the parking lot
Cappelaere we need to pick
Cappelaere most of thos estories have sponsors
Cappelaere Map Symbology?
Cappelaere I would love to see many links to cool maps on the wiki or somewhere
Cappelaere yes/No?
madair perhaps an email on the users list to solicit input?
Cappelaere sure
Cappelaere 1+
CameronShorter Pat, I think we need to first find a volunteer who wants to do the work (ie right now).
Cappelaere I volunteer
Cappelaere and ask for help
CameronShorter ok, +1
Cappelaere stvn?
Cappelaere can someone else vote? or PMC only?
CameronShorter Actually before deciding whether we accept it in the build I'd like to see the techincal design. But I agree to the use case.
Cappelaere mike?
Cappelaere ok
Cappelaere that's the idea
Cappelaere we are voting to put it on the backlog and further expand on it
Cappelaere Map Symbology?
madair sorry what the vote on? moving MapSymbology to the backlog?
CameronShorter I think the PMC should make major decisions about the design of the project (like this).
Cappelaere vote was for Map Repository
CameronShorter But other peoples input is welcomed.
Cappelaere vote is to put item on backlog or refuse it
Cappelaere mike?
linda____ is it important to keep a list of the rejects around?
madair the map repository thing sounds more like a registry issue
Cappelaere will stay on parking lot with reject
madair I don't think we have a mapbuilder "portal" yet
Cappelaere agree but what is your vote?
Cappelaere again we are voting to move items to backlog andnot to run and implement them yet
Cappelaere or not
madair -1? The way it's described there sounds like it's moving away from the core Mapbuilder library creating a portal
madair I've been meaning to write some comments like this (but haven't had time yet)
Cappelaere Cameron: What do we do now?
madair I can see this being some mapbuilder models and widgets to query a catalog/registry
Cappelaere The idea was to have a wiki page with a bunch of links on weher you can get access to map data
Cappelaere this is critical for a lot of users to get started
CameronShorter Pat, what about if you changed the feature so that you create a widget/model which allows users to select a feature set. The feature set comes from an external source (not on Mapbuidler).
madair Pat: taht part I agree with, but it's not really lib development
madair or am I missing something
Cappelaere you are right
Cappelaere I think this is a missing piece for new users
Cappelaere we need to expand a bit
Cappelaere mapbuilder-lib
Cappelaere mapbuilder-maps
Cappelaere mapbuilder-icons...
CameronShorter What about if we created a new project for the icons, under a new directory.
CameronShorter Yes.
Cappelaere You are talking implementation now
Cappelaere this would be next step
CameronShorter I think implementation is important here because it determines which way we vote.
linda____ there are two parts
Cappelaere k
linda____ first is it a desired feature
linda____ then how is it implemented
madair sorry I'm going to have to sign off, much to do before my trip
CameronShorter As the PMC, we will need to consider how it is implemented before we vote because the implementation may be undesirable for the project.
CameronShorter ok Mike, thanks for coming.
Cappelaere have a good trip
linda____ maybe I'm missing something here ...
madair bye
* madair has quit ("Leaving")
Cappelaere If it is moved to backlog, it would still have to be reviewed from an implementation standpoint and approved
linda____ but the definition of features being accepted or not into the code base
linda____ is always up to the PMC
linda____ by definition of our open source nature ultimately the implementation is up to the actual developer doing the code
CameronShorter Linda, yes that is correct. But we welcome input from people like you.
linda____ now with that said it behooves the developer to implement it in a fashion which is acceptable to the PMC so that it will be included in the next release
linda____ there by leveraging the community
Cappelaere it is a multiple step process
linda____ (over stating the obvious definition of open source )
Cappelaere input to parking lot
Cappelaere move to backlog
Cappelaere move to implementation/test
Cappelaere accepted into code base
CameronShorter Linda, the nuts and bolts of the design will be up to the developer, but the PMC is responsible to make sure any development doesn't break our design goals (like unstable code, or creating a image to large to download).
linda____ Agreed ...
Cappelaere agree
CameronShorter um...
linda____ my personal experience with open source development is that I will take a snap shot of the code base
linda____ do my additions / bug fixes / major enhancements
linda____ then offer them back to the community
Cappelaere so the intent here is to just move it to backlog and then review expanded user story and proposed approach
Cappelaere May be it is too complex?
CameronShorter Pat, as we walk through this process, I'm beginning to wonder whether SCRUM as it stands is right for an open source.
CameronShorter I think linda is on track here.
CameronShorter I think the process is closer to:
CameronShorter (no User Story)
CameronShorter * Developer offers to add a feature
CameronShorter * PMC agrees to the design, makes suggestions, etc.
CameronShorter * Developer creates the code.
CameronShorter * Co-developers review
CameronShorter * Add code to codebase
CameronShorter * Test etc
linda____ I do like the idea of having the parking lot, back log, etc
linda____ because it gives developers an idea for what is possible
linda____ and what the community is thinking
CameronShorter I think the parking lot would work better if we called it a "wish list"
linda____ of taking the product
Cappelaere sure. same thing
Cappelaere This also gives us visiblility into what is being worked on in the immediate feature and who is doing it
CameronShorter And we only need one "Wish List".
Cappelaere I can rename User Stories Parking Lot to USer Stories Wish List
linda____ well I would still like two lists total
CameronShorter I don't think we need to support the overhead of having 2 lists and review the contents of one to move into theother.
linda____ what we are currently working on
linda____ and wish
CameronShorter To get something onto the wish list, a developer should discus their idea on email first, then after agreement, add it to the wish list.
linda____ the wish list could have prio set by the PMC
CameronShorter Linda, yes, good idea.
linda____ which in theory would give us the two lists in one
CameronShorter Linda, the wish list could be handled by the Confluence issue tracker.
linda____ exactly
Cappelaere isn't the difference purelt semantic?
Cappelaere purely
CameronShorter The for a release we can identify which bugs/features are targeted for a particular build and track progress. (Confluence provides this functionality)
CameronShorter Pat, probably.
Cappelaere I think we are talking about the same thing
Cappelaere The only little difference is that we are expanding the one-liner into a small paragraph to make sure everyone understands what is planned and to make sure it canbe tested
Cappelaere theone-liner would go into Confluence for scheduling/tracking
CameronShorter I'd like to see implementation details in the description so we can make a technical decision as to whether the feature is good for the project.
CameronShorter Lets see what Linda comes up with regarding Confluence.
linda____ Update: there is a bugzilla->Jira converter ... so it looks good
Cappelaere Agree. The intent was to expand on it once on the backlog. Force the developer to expand on the user story and talk about implementation
Cappelaere and make sure it is testable.
CameronShorter Linda, I don't think SF uses bugzilla.
linda____ oh really
linda____ hummm
linda____ well
linda____ I'll figure out something
CameronShorter I'm pretty sure SF has a roll-your-own.
CameronShorter bugtracker.
linda____ then web scrappint it is
Cappelaere would you like to change the approach?
CameronShorter If you search through the SF docs on bug tracking you should be able to find an XML export function.
linda____ yea I'm just looking at SF now
CameronShorter Pat, how is that?
Cappelaere Are we back on use stories?
Cappelaere What would you like to see?
CameronShorter Pat, we probably shouldn't approve the stories without at least 3 PMC members in the room.
Cappelaere Agree. I am talking about intent/process
CameronShorter ok.
CameronShorter Assuming Linda works out Confluence, I'd suggest each story be moved into Confluence.
linda____ I would be so bold to suggest that we make the decision to go to confluence today
Cappelaere Who puts user story in Confluence?
linda____ and we will get the stuff from SF into Confluence as fast as we (I) can
CameronShorter I'm happy to go to confluence if we can get the CVS bugs into it.
CameronShorter Pat, anybody can add stories to confluence.
Cappelaere How do you remove them if you disagree?
Cappelaere or PMC disagree
Cappelaere just delete?
CameronShorter Yes.
linda____ my personal vote is that no idea is deleted
Cappelaere agree
linda____ just change the tag
Cappelaere That's what we were trying to avoid
CameronShorter But because the idea is in confluence we will have a record of all deleted suggestions.
Cappelaere Can we have a deleted tag? I guess...
CameronShorter (You cannot delete an issue, only put it in the "deleted" status)
linda____ agreed ... or "rejected by PMC"
CameronShorter Sure.
Cappelaere So do we want to move Parking Lot to Confluence?
CameronShorter I'd like to make that call after Linda is happy to get bugs in confluence.
Cappelaere fine with me
Cappelaere She will get it done!
Cappelaere
CameronShorter If we don't have bugs in confluence, we can use the SF feature request list.
CameronShorter Linda, we have a few issues in the feature request list already.
CameronShorter Which will need to be copied across.
linda____ there are less than 50 open bugs
linda____ worse case I get them over via scraping
linda____ best case they all come over via XML
CameronShorter ok
CameronShorter It would be excellent if you could get this done.
linda____ short term goal get all open in
linda____ long term get closed ones in
CameronShorter I think it is accpetable not to move the Closed bugs across.
Cappelaere agree
linda____ oh ... ok
Cappelaere But we would need to move Parking lot to Confluence
Cappelaere which is not bad
CameronShorter Pat, yes.
Cappelaere k
CameronShorter It is possible in Confluence to tailor your workflow. (might be work seeing how other projects do this.)
CameronShorter Eg, Geoserver or Geotools.
CameronShorter I mean see how they handle feature requests.
Cappelaere Geospatial Foundation Meeting?
Cappelaere MapBuilder should be represented
CameronShorter What is this meeting?
Cappelaere Did you see Mike's email?
CameronShorter reading
CameronShorter yes, it would be great to get someone down there.
Cappelaere I could probably go. I think.
CameronShorter But unless someone wants to pay my air fairs, it won't be me.
Cappelaere They are proposing to pay for airfare
Cappelaere ask them
CameronShorter yes, I'll do that.
Cappelaere Then stop by Baltimore and we can all have crabs for dinner
linda____ hey that's my line
Cappelaere at Linda's
linda____ LOL
CameronShorter sounds good.
Cappelaere what else?
linda____ topic wise?
Cappelaere yes
linda____ People having SVN issues
linda____ I have seen some traffic
linda____ but not sure that everyone is up and running
CameronShorter I think I'm the only one left not working on windows.
CameronShorter (I'm working on Linux)
linda____ k
linda____ isn't may people left on line
linda____ so I would be happy to work with you to get you up and running
CameronShorter I'm going to try and work out tortoiseSVN .
linda____ or some time later
linda____ I have that on my desktop
linda____ and it seems to be a fine explorer extension
CameronShorter Reading through the Geospacial Foundation email...
CameronShorter It seems that the topic will be legal rather than technical.
CameronShorter Which is of less interest to me.
CameronShorter So I might attend via IRC instead.
CameronShorter Linda, have you used tortoiseSVN with SSH yet?
linda____ I use absolute telnet to do my ssh tunneling
linda____ I honestly think it is easier to use myEclipse
linda____ since it has the plug-in for SVN
Cappelaere c'mon Cameron!
linda____ what are you using for your development IDE on windows?
CameronShorter vim
linda____ LOL
Cappelaere geeeez
linda____ got to love it
linda____ yea like you have a lot of room to talk patrice
linda____ how long did you use vim on windows
CameronShorter Ever since I moved from unix to windows.
linda____ well to make you feel at home
linda____ you can use the VI editor plugin for eclipse
linda____ and you will feel just like home
Cappelaere Oh
CameronShorter ok, I'll download myEclipse and have a look.
Cappelaere But why would you?
linda____ I have never tried it my self
linda____ hey if you have to think to do your edits then you are slow
linda____ I cannot tell you the number of time I have found my self typing ZZ when wanting to save a file
CameronShorter
linda____ ok anything else?
CameronShorter which release should I download?
CameronShorter 4.0 or 4.1
linda____ need to get eclipse first
linda____ them myEclipse 4.1
linda____ opps sorry typo'd that one
linda____ 4.0 MyEclipse
linda____ 4.0.3 GA
linda____ http://subclipse.tigris.org/
linda____ then that for the plugin
linda____ I believe that Patrice was able to copy his keys from his Mac to windows machine
Cappelaere affirmative
CameronShorter ok
CameronShorter Downloading now.
CameronShorter Pat, do you want to talk about Vector graphics design?
Cappelaere Sure
Cappelaere It is currently used to support GeoRSS feeds
CameronShorter I think we need to restructure the way we use the WMC document and redering of layers (with MapPane).
Cappelaere You create a VectorGraphics Object
Cappelaere and start writing to it
Cappelaere the type of object you really get dependson your platform
CameronShorter We currently have a problem is that non-WMS layers don't get included in the LayerList widget and and not included in the WMC.
CameronShorter Pat, that sounds right.
Cappelaere I currently get GML info from GeoRSS feed
Cappelaere georss:where tag
Cappelaere I render GML:POINT, GML:LINSTRING and GML:POLYGON
CameronShorter I propose that Context.xml is expanded to include reference to GeoRSS layers, WFS Layers, GML layers etc.
Cappelaere you lost me
CameronShorter The MapPane.paint should loop through the layers, then farm off the layer rendering to different layerRenderers.
CameronShorter Sorry, I'm one level below the rendering.
CameronShorter I'm currently talking about how we describe the layers on the mapPane.
Cappelaere So GeoRssRenderer would create a layer which would get rendered differnetly
CameronShorter And I want to include point layers into the Context so they can be included in the LayerList (also known as Legend).
Cappelaere I like that idea
Cappelaere I would like to have ship tracks on different layers so you can turn them on/off
CameronShorter Yes.
Cappelaere Iwas doing that with Flash
CameronShorter So if the Context now knows about all the layers, MapPane can be responsible for marshalling the rendering of all the layers.
CameronShorter Currently MapPane is responsible for rendering only WMS layers.
CameronShorter MapPane.paint should be simplified so that it calls XxxLayer.paint() for each of the layers.
CameronShorter Make sense?
Cappelaere I think so.
Cappelaere Seems like a major change
Cappelaere but doable
CameronShorter Yes.
Cappelaere right now GeoRSS is a model
CameronShorter Initially it should only involve moving code from one class to another.
Cappelaere but it could create one or more layers into current model
CameronShorter yes
CameronShorter So you should still have a GeoRSS model.
Cappelaere right
Cappelaere config file does not change
CameronShorter no, I don't think so.
linda____ (changing topics) the xml dump from sourceforge is failing because the detail section is not <![CDATA[
CameronShorter Linda, yes. XML dump is not valid XML.
CameronShorter Might be easier to do HTML scraping. I'm not sure.
linda____ but easy to fix via Slickedit search and replace of the <detail> tags to <detail><![CDATA[
Cappelaere then use MapPane and add GMLLayers
linda____ and likewise for the closing tags
Cappelaere Make sure that MapPane can recognize the layers
Cappelaere layer types
Cappelaere add a WMSLAyerRenderer and GMLLayerRendere
CameronShorter Pat, yes the layerTypes would need to be identified in the context.xml
Cappelaere why would that be?
CameronShorter Pat, yes. about the renderers.
Cappelaere that's kinda internal
Cappelaere the models know what layer types are being added
Cappelaere and it better match
CameronShorter brb
linda____ ok have valid XML file with converting summary, text and detail to be CDATA sections
linda____ so step one done
Cappelaere Looked at MapPane. I am not sure it simplifies it a whole lot but it allows us to deal with layers in a common way
Cappelaere The trick is on the GMLLayerRenderer side
Cappelaere I need a common document format now
Cappelaere which I was trying to postpone
Cappelaere But I think that's ok
linda____ the old pay me now or pay me later
CameronShorter I'm about to run off and have breakfast with the family, but will probably be back in 45 mins or so.
linda____ k
CameronShorter Very quickly:
Cappelaere k
CameronShorter MapPane should call XxxLayer.paint()
CameronShorter the VectorLayers.paint() will call Graphics.drawLine() and other graphics functions.
CameronShorter Depending on what browser you use, will determine which graphics library gets called by Graphics package.
Cappelaere k
CameronShorter (Think AbstractFactory for handling the Graphics rendering).
Cappelaere yeap
Cappelaere WMSLayerRenderer and GMLLayerRenderer
Cappelaere derived from LAyerRendere and override paint
CameronShorter yes, althought I think you can call them WMSLayer and GMLLayer
Cappelaere MapPane.paint calls LayerRenderer for each layer
Cappelaere k
CameronShorter yes
CameronShorter We better run this design past the list before implementing.
CameronShorter As it is a fairly fundamental change.
CameronShorter Of note, if we use the above design, it will make it very easy to add a GoogleMaps layer.
CameronShorter ok, off to breakfast.
Cappelaere k
linda____ cya
Cappelaere have a good day?
Cappelaere or evening?
Cappelaere you are Sat morning
linda____ !time
Cappelaere Have a great weekend then
linda____ yes he is ahead of us
* Cappelaere has quit ("Quit")
* linda____ (n=lderezin@pcp0010489598pcs.essex01.md.comcast.net) has left #mapbuilder
Labels