Many thanks for the info - keep us posted of your development

Cheers

Nick

About this question, no it won’t be slower unless you add really huge cartography files to background, however I don’t believe that can occur (getting slower) because I already tried that with other projects.

Also about speed (or getting a bit slow) it’s happening because when the client connects to the server he is actually connecting and processing all the information on the fly which will end up creating some views that can be later queried by the client and are also displayed in the map.

So, to make this approach faster it’s easy, by using the DBMS crate views or event schedule a script for creating and deleting tables during maintenance time will improve a LOT the speed.

This approach was intended to test&identify the potential issues regarding recorder development and try to understand how heavy the database can be, which will reflect the amount of processing requisites for a feasible web application.

The next step is to perform a few server programming to improve the speed that will improve the above.

About queries available you can find a few of them mainly in 2 locations.

The “Query Manager” allows you to select a few of them, however more of them could be added, it just depends of what you want to allow the user to query, in these case since I’ve a lot of work haven’t the time, so I just recommend to try it.

There’s also spatial queries already available (more info with images here http://internal.bio3.pt/recorderlive/concept.html) . By using the buttons you can perform  2 types of queries; on one hand you can create a point, build a buffer and select the action for that buffer (taxon or biotope); or on another hand you can build a polygon and get the associated data from it.

Basically, Openlayers is one of my favorite opensource GIS visualizer , but I´ve never tried OpenLayers for Recorder GIS but I believe that’s possible to get something interesting from it.

Regarding this platform I’m more like a user not like a developer for the moment.

It’s possible to run on PHP however this example is pure ASP and it's bsed on a commercial GIS application not opensource.

Regards.

The initial interface looks good but (as you say) the system is a bit slow. I therefore wonder whether it will be even slower once you add some background mapping?

I am also not clear what the advantage is for your proposal - can you not query the data from the database and use existing systems (e.g. OpenLayers - Charles I too have been testing this out) for displaying? So unless the system is really fast, most people may not get the best out of your system.

Incidentally, will your solution run on PHP?

Cheers

Nick

I've been developing a webgis based entirely on recorder database.

There’s already a public version with some minor bugs and is currently living at ---------> http://internal.bio3.pt/recorderlive

This version is a bit slow when running some queries, because all this data is being processed on the fly, with will end up delaying the application a bit.

By this approach which is powered by the recorder database without any middle DBMS or any tools besides of course the GIS platform behind it intended to understand some problems related to the delivery of the recorder data base online using a webgis.

The next step is working the integration and strategy of delivering this data over the internet,  in a faster and better way.

Regards.

Not really come to any hard conclusions yet. This area of IT is moving so fast, it's best to stay as agile and agnostic as possible.

As far as mapping goes, I (we) have been looking at OpenLayers lately. No live demos to show off yet, but soon, hopefully. ;)

Charles

Did you reach any further conclusions or made any further progress with this Charles?

The problem is there are a plethora of options, each requiring a lot of input and time to learn properly. Like others I already had experience in PHP and MYSQL and for web-mapping eventually went down the Mapserver, PHP-Mapscript, MySQL route. After a LOT of hair-tearing trying to manually configure Mapserver I discovered the FGS package which basically sets everything up for you in separate server environment. I also ended up eventually using Javascript msCross http://mapserver.gis.umn.edu/docs/howto … ng-furtherfor the interface. This has limitations (like no way I can see to query the map) but is simple, fast and effective in many ways.

One of my rather primitive efforts (I only do this part-time) is here:

http://www.bsbimaps.org.uk/tetrads/main.php

I'd be interested in seeing examples of what other people are doing and hearing what technologies they are using.

Cheers

Alan

PS - the FGS community seems small but very helpful

Dave, any reason you chose Adobe technologies (AIR/Flex) over plain old HTML and Javascript (Ajax)?

I find HTML/JS/AJAX just such a clunky way of doing things. I know people have done wonderful things with these technologies, but I find it hard work. Flex offers desktop type controls and interaction and I can build my interface visually and script events in one IDE then just run it in the flash player or on the AIR runtime. Flex also has great data controls which are vital for our work.

I see this as a set of interfaces which sit embedded within a web page within a CMS - we are using Drupal as it's on tap at our ISP. As noted, we got Flexbuilder free via the Adobe educational program.

Sorry for the late reply, I've been on leave.

Thanks again.

Charles

particularly if you are reluctant to splash out on Adobe Flex

I didn't realise this either, but Flex is free and open source. That just made it a whole lot more interesting to me. A whole lot more interesting indeed. It's just Flexbuilder, the IDE, they charge for. I was considering what I should use for desktop development (I was considering .NET, mainly), but this seems like it may be a better alternative given my web background and preference. I'd always been put off because I loath Flash (the application, rather than the technology itself). I might have to revisit it I think.

But, argh. Just too much stuff to play with and too little time!

Nick, as a long time user of PHP and MySQL, it's tempting to simply use those, but I've started using other technologies lately (including Ruby and Rails), plus we already use ESRI kit, so the benefits of using PHP and MySQL aren't quite so apparent here. I still use them for our basic website, though.

So for guys like me who build everything from the bottom up (particularly if you are reluctant to splash out on Adobe Flex, ArcGIS Server etc.), then perhaps PHP/MySql is not a bad starting point for cutting your teeth on web gis development.

So I guess it is horses for courses ;)

EDIT - forgot to mention, users access the system through PHP pages e.g. http://www.nesbrec.org/thesaurus2.php (searching on NBN's dictionary) giving a result e.g. http://www.nesbrec.org/species_map.php? … ra%20lutra based on live data updated nightly using Navicat. If you click on a grid square you get a more detailed map. 

Cheers

Nick

Once the interfaces are build (Adobe Flexbuilder seems really good. Having tried this we have ordered it) these will act as input/output to the scripts.

Cheers.

PostGIS runs all of our internal spatial enquries, generates spatial datasets for internal GIS and data products going outside. We have a couple of applications which are semi-automated where data from outside organisations gets uploaded into the database for searching and then reporting.

It hold subsets of biological data in a form for fast web queries and interface to web mapping. (Mapyrus). This is not quite there yet as version three of our web site is under testing. Also, our intranet and extranet applications use Postgres.

The link to Recorder is one table which holds fields from the SAMPLE table. This is updated automatically on a daily bases, or manually as needed. External scripts join spatial results to Recorder's data and put that back into Postgres as records and taxa. Our system uses 'tickets' to reference jobs and queries.

We also hold constraints layers such as VC boundaries, wildlife sites, roads networks, SSSI, SAC etc. These mirror the layers on the desktop GIS, so any programmed GIS work using PostGIs uses the same layers.

So, in short, we use it as a programmable GIS and as a "normal" DB to hold managment information.

This looks interesting:

http://abegillespie.blogspot.com/2008/01/ziggis-20-official-announcement_07.html

It's looking like PostgreSQL is nudging ahead at the moment, simply because it seems a bit more advanced, plus it is being supported by ArcGIS in version 9.3.

I'm actually also quite tempted by the new ArcGIS Server. That might ultimately require learning .NET or Java, but I'm not adverse to that as such.