We have fixed the browser refresh problem by creating a Model/View/Controller design pattern entirely on the client. The Model is stored in XML inside a javascript class. When the user changes data on the client, the Model is updated, which sends events to our widgets which redraw themselves. No interaction with the server is required, and no complete rebuilding of the web page. Demo appliation is at: http://bikemap.openearth.com.au:8080/mapbuilder/de mo/simple/
I figure I will probably be flamed for this, such is life.
I worked in a company with web developers, sales people, coders and more. We had PC's, Macs, Linux, and everyone had different ideas about what package to use for documenting (from word to vim).
The key mechanisms you want out of a doument management system are: * Store documentation in a standardised format. * Use a Versioning system which will track users and differences between versions. * Ensure that the data you put into the versioning system comes out in the same format.
If possible try and get everyone using Linux, or tools compatable with Linux. However you might be like us and not have the power to wean the rest of the company off microsoft.
In that case, you can go entirely commercial (Rational have some nice stuff for version managment) or try the following.
Use CVS as the version managment system. Store your docs in either html, , sgml, xml, or txt.
For HTML there are plenty of editors in numerous plaforms.
Have a look at the Linux Documentation Project for SGML editors.
It is possible to convert word documents from: Word->rtf->xml or html-> put into CVS (and then go back again. This does require management at the word end to ensure diagrams are referenced outside the word document rather than imported in. (Check the import options in word).
Word docs can be stored in CVS, but they need to be stored in binary format, consequently you cannot see the differece between them by doing a "cvs diff".
Unfortunately, using word docs means that the linux guys are forced to read them - yes, there are ways, but it is a righ pain in the arse.
I've worked on military software (mainly submarines) for 10 years, and I agree, I'd hate to see some of it open sourced and used by unresponsibly nations.
However about 70% of the code could have been used for every day type purposes. Things like databases, sorting algorithms, modem testers, bug tracking systems, and so on.
Code can be broken into a few areas: 1. Core code (the bit that drives the submarine). This needs strict QA and the customer will gain little by trying to use open source code here. Code written which requires strict testing should be written differently, to minimise the number of decisions made in the code and reduce testing. However if you can convince your customer to open source some of the vanilla code, then you should be able to add some well tested code to the Open Source Community.
2. Supporting code. These are you test harnesses, bug tracking, CVS etc. You should find some of these programs can enhance existing open source applications.
3. Protocols. Look out for opportunities to use and enhance standard protocols rather than propriety ones. This will be good for the customer because their protocols will not become outdated as fast, and good for open source because there will be a big user putting money behind standards. (I know US military are putting money behind the Open GIS consortium to standardize map protocols on the web, and this is having flow on effects into open source GIS applications that I'm working on).
It is still vapour-ware, but by the end of the year I expect to have a web based tool which will allow a user to see a map of a city in a web page, say "here is a good place for a node", click, click, submit.
The data is sent to a database and the presented back to the uses over the web.
Collecting wireless node locations would be an ideal use case.
Interoperable Webmapping
80% of the cost of mapping projects is finding basemaps and integrating with them. There are huge amounts of GIS data around, and being able to store current versions of all the GIS data you require is often unobtainable.
Consequently the Open GIS Consortium are developing where data custodians look after the data, and serve it to the web, then application builders access these data layers (from multiple servers) merge them then present them to a user.
This is all being made possible by the development of standards for a series of Network Addressable Services.
Cameron Shorter - Web Mapping Manager
Social Change Online http://webmap.socialchange.net.au
Slashdot Mirror
We have fixed the browser refresh problem by creating a Model/View/Controller design pattern entirely on the client.e mo/simple/
The Model is stored in XML inside a javascript class. When the user changes data on the client, the Model is updated, which sends events to our widgets which redraw themselves. No interaction with the server is required, and no complete rebuilding of the web page.
Demo appliation is at: http://bikemap.openearth.com.au:8080/mapbuilder/d
The project is at: http://mapbuilder.sourceforge.net/
I figure I will probably be flamed for this, such is life.
I worked in a company with web developers, sales people, coders and more.
We had PC's, Macs, Linux, and everyone had different ideas about what package to use for documenting (from word to vim).
The key mechanisms you want out of a doument management system are:
* Store documentation in a standardised format.
* Use a Versioning system which will track users and differences between versions.
* Ensure that the data you put into the versioning system comes out in the same format.
If possible try and get everyone using Linux, or tools compatable with Linux. However you might be like us and not have the power to wean the rest of the company off microsoft.
In that case, you can go entirely commercial (Rational have some nice stuff for version managment) or try the following.
Use CVS as the version managment system.
Store your docs in either html, , sgml, xml, or txt.
For HTML there are plenty of editors in numerous plaforms.
Have a look at the Linux Documentation Project for SGML editors.
It is possible to convert word documents from:
Word->rtf->xml or html-> put into CVS (and then go back again.
This does require management at the word end to ensure diagrams are referenced outside the word document rather than imported in. (Check the import options in word).
Word docs can be stored in CVS, but they need to be stored in binary format, consequently you cannot see the differece between them by doing a "cvs diff".
Unfortunately, using word docs means that the linux guys are forced to read them - yes, there are ways, but it is a righ pain in the arse.
I've worked on military software (mainly submarines) for 10 years, and I agree, I'd hate to see some of it open sourced and used by unresponsibly nations.
However about 70% of the code could have been used for every day type purposes. Things like databases, sorting algorithms, modem testers, bug tracking systems, and so on.
Code can be broken into a few areas:
1. Core code (the bit that drives the submarine). This needs strict QA and the customer will gain little by trying to use open source code here. Code written which requires strict testing should be written differently, to minimise the number of decisions made in the code and reduce testing.
However if you can convince your customer to open source some of the vanilla code, then you should be able to add some well tested code to the Open Source Community.
2. Supporting code. These are you test harnesses, bug tracking, CVS etc. You should find some of these programs can enhance existing open source applications.
3. Protocols. Look out for opportunities to use and enhance standard protocols rather than propriety ones. This will be good for the customer because their protocols will not become outdated as fast, and good for open source because there will be a big user putting money behind standards. (I know US military are putting money behind the Open GIS consortium to standardize map protocols on the web, and this is having flow on effects into open source GIS applications that I'm working on).
It is still vapour-ware, but by the end of the year I expect to have a web based tool which will allow a user to see a map of a city in a web page, say "here is a good place for a node", click, click, submit.
The data is sent to a database and the presented back to the uses over the web.
Collecting wireless node locations would be an ideal use case.
For more info, check out http://mapbuilder.sourceforge.net.
PS, Any developers who want to help out would be warmly welcomed.
Free GIS URLs
http://freegis.org/
http://opensourcegis.org/
http://www.opengis.org/
Interoperable Webmapping
80% of the cost of mapping projects is finding basemaps and integrating with them. There are huge amounts of GIS data around, and being able to store current versions of all the GIS data you require is often unobtainable.
Consequently the Open GIS Consortium are developing where data custodians look after the data, and serve it to the web, then application builders access these data layers (from multiple servers) merge them then present them to a user.
This is all being made possible by the development of standards for a series of Network Addressable Services.
Cameron Shorter - Web Mapping Manager
Social Change Online http://webmap.socialchange.net.au
And geotools, which does the same sort of thing and is GPL: http://geotools.sourceforge.net/