[Community] Does my GIS project stand a chance?
Jan van der Ven
j.vanderven at magion.nl
Fri Apr 4 10:19:58 EEST 2008
Dear Eric, Josh and the rest,
Thanks again for the quick response.
You raise interesting points for discussion. Let me think out loud.
The first editable shape contains lines and the second contains polygons.
These polygons are made up of 4-10 points, and the average number of points
will be close to 4. As editing is not a daily exercise, I think we can get
away with image overlays, and start the editable bit when zoomed in to a
certain amount. The only case where the whole area would be displayed is
when we show a selection of these polygons based on some filter criteria. We
then want to show the map on a size that contains all objects.
But the normal work is done when zoomed in to an area of about 200x200
meter.
I think I need to add layer(s) to render the editable objects in a different
colour based on state. This state is a Plone (workflow) based thing. So I
need to generate a layer from the ZODB I think. Which, if I understand you
correctly, implies the use of zgeo.wfs.
The non-editable layers do contain textual information that we need to
display upon selection, but this content will not be edited.
In your two responses I find a contradiction concerning PrimaGIS: Eric says
mapserver needs access to it, to be able to edit the points, but Josh says
that with extra middleware such as FeatureServer it is possible.
If you need more information, do not hesitate and ask.
Kind regards,
Jan
-----Original Message-----
From: Josh Livni [mailto:josh at umbrellaconsulting.com]
Sent: Thursday, April 03, 2008 19:28
To: gispython.org community projects
Cc: j.vanderven at magion.nl; ebrehault at gmail.com
Subject: Re: [Community] Does my GIS project stand a chance?
Hmm, I guess I see the two proposed solutions less as software-centric
(PrimaGIS vs zgeo.wfs), and more as data-source/display options, eg WMS
overlays vs Vector overlays. This discussion applies only to the two layers
of interest: those that need to be edited and potentially have their
attributes and/or geometries stored in the ZODB. The other layers it seems
can just stay as shapefiles or rasters, and perhaps PrimaGIS would be a nice
solution for displaying these and dealing with the shapefile cartography
within Plone - or perhaps it would not be worth the effort. In any case,
back to the layers of interest:
Displaying 5000 points, let alone polylines or polygons, is going to trash
most any browser. So to me the questions are: do you need to display all
editable layers' data at once? If so, and you want vector overlays, can you
get away with clustering the data such that less points/vertices are drawn
at a given time (quite feasible, but potentially a bit of a hassle)? Or
would it be better/easier to display as these layers as image overlays
(WMS), and then as vector overlays as well when editing them (and
potentially when zoomed in a lot)?
Once those questions are answered, I think then you can look at the best
tools for the job. For example, and I am not necessarily recommending this,
but if you don't need your editable layers to have any attributes aside from
those already in the shapefiles, and you only need to add editing capability
to the layers, then you could simply keep the data as shapefiles, have
Mapserver serve them up as WMS overlays to an OpenLayers Map (possibly via
PrimaGIS, possibly not), and then use something like FeatureServer as a
middleware to edit the shapes and write changes back to the shapefiles.
Or, assuming these layers are actually full of features that should be
robust Plone content rather than rows in a shapefile, then something like
zgeo.wfs could be used. And then the trick is maybe only how to display the
data as a WMS when zoomed far out. I imagine it would not be super
difficult to write something that takes data from the zodb and exports it to
a shapefile (or rather, updates a shapefile) whenever a change is made. Or
can PrimaGIS maybe now use ZODB geodata as a WMS source thus making this
whole discussion moot?
Anyway, I realize I haven't done a great job of explaining a software stack
I would recommend - my point is just that you should decide if your use case
requires that data can/should be displayed only vector overlays (they will
need to be vectors of course when you edit them), or if you also need to
display them as image overlays (quite possible, it seems). That is a key
piece to know ahead of time before deciding on any particular set of
software.
As always, Sean and others have done great examples of displaying lots of
geographic data in Plone, so I am sure more folks have additional and
different opinions than mine for you to consider :)
-Josh
Eric Bréhault wrote:
> Hello Jan,
>
> If you want Plone to be the core piece of your architecture, there are
> 2 solutions:
> - solution 1: you use PrimaGIS
> PrimaGIS will use MapServer to display your shapefile layers as you
> want to be able to edit your georeferenced plone objects geometry, you
> will have to store your spatial info in a place where it can be
> accessed by MapServer, (so it cannot be the ZODB), so you have to use
> Postgre+PostGIS
>
> in this solution the difficult parts are: get the edited geometry from
> the client, store it in ZODB and synchronize it in Postgre/PostGIS
>
> - solution 2: you use zgeo.wfs
> with zgeo.wfs, all your georeferenced objects are stored in the ZODB,
> and their geometry too you do not need MapServer to access them as a
> layer, you do not need to use Postgre/PostGIS and you can display this
> layer in OpenLayers (which is 100% client-side), and you can edit the
> geometry throught OpenLayers because it supports WFS-T of course you
> will need MapServer to serve your shapefile as WMS layers but the good
> thing is you do not need any external component to access and process
> your Plone objects geometry
>
> in this solution, the difficult parts are: zgeo.wfs does not support
> WFS-T at the moment (but I can work on it) + I have currently no idea
> about the performances when handling about 5000 objects (but I can
> make some tests)
>
> Regarding the architecture, I think solution 2 is much better.
>
> If you consider using zgeo.wfs, I will bring you my entire support.
>
> Regards,
>
> Eric BREHAULT
>
>
> On Thu, Apr 3, 2008 at 5:31 PM, Jan van der Ven <j.vanderven at magion.nl>
wrote:
>
>> Dear list,
>>
>>
>> Much has happened since my last post. The most important is that the
>> project is on!
>>
>> I have seen how they use their old software, and plone is indeed
>> what they need.
>>
>> I also heed Sean's advice: "Generally, PrimaGIS is a solution when
>> Plone is the major piece of your intranet and you *do* have other
>> spatial data (shapefiles or spatial databases)." So I think we should go
with PrimaGIS.
>> Plone has moved to 3.0.6 and we would like to use that. But the
>> PrimaGIS version for that Plone has not been officially released. Is
>> there a reason for that? Is there something we can do?
>>
>> At the moment there are several layers (all of them shape files).
>> One of them is made up of aerial photo's but the quality is so poor,
>> that Google Earth is used instead, but not in the same map. Of
>> course, we want to integrate that into the same map. Two of the
>> layers are editable, which means that the polygon or line can be
>> moved and/or changed and new ones can be added, and as I mentioned
>> before, there are about 5000 of them. These layers are now shape
>> files but if there is a better storage format, we may be able to
>> convert them. A nice feature would be that the colour of the
>> line/polygon would be dependent on state. I know that can be done
>> with separate layers, but is there another solution? The
>> geographical information will go into the ZODB (with the insight we
>> currently have). If an update of a 'read-only' layer is received, some
kind of 'diff'erences report is desired.
>>
>> I am now going to ask a newbie question: what software is available
>> to fullfill this set of tasks? And then the dreaded question: where
>> will we find the biggest pain?
>>
>> Any suggestions will be greatly appreciated.
>>
>> Kind regards,
>>
>> Jan
>>
>>
>> No virus found in this outgoing message.
>> Checked by AVG.
>> Version: 7.5.519 / Virus Database: 269.22.5/1357 - Release Date:
>> 03-Apr-2008
>> 10:48
>>
>>
>>
>>
>> _______________________________________________
>> Community mailing list
>> Community at lists.gispython.org
>> http://lists.gispython.org/mailman/listinfo/community
>>
>>
> _______________________________________________
> Community mailing list
> Community at lists.gispython.org
> http://lists.gispython.org/mailman/listinfo/community
>
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.5/1357 - Release Date: 03-Apr-2008
10:48
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.5/1357 - Release Date: 03-Apr-2008
10:48
More information about the Community
mailing list