[Community] Display text from shapefile or PostGIS into themouseover popup

[Sean Gillies]

On Dec 9, 2005, at 11:14 AM, Moisan Yves wrote:

>> Here's one use case:
>> I have 1 shapefile for last 5 years showing projects done in that
>> particular year. The shapefile has field for contact information and
>> project url that I would like to be able to show to the users.  In my
>> case, I have just a few layers (country boundary, state boundary and
>> projects). I wouldn't want mouseovers for country or state. I  
>> could use
>> labels for those. However, it would be immensely useful to display  
>> a brief > project description in the mouseover.  This is a very  
>> simple use case
>> which I believe could be applied to all kinds of situations.
>
> Popups do have the ability to make a map more legible since they  
> hold information that otherwise would need to be burned-in as  
> labels, so that's one good point about popups.  In order to strike  
> a balance between what can be represented as a label and what would  
> benefit from a popup (and to avoid label or popup overload), I'll  
> venture a definition of a popup :
>
> Popups are more or less rich-content hyperlinked labels with  
> visibility turned off by default.
>
> To me, the most important point is the hyperlinking  
> functionnality.  A road name clearly only needs a label, unless  
> you'd want to gain a url to some artifact related to that road ...   
> The second most important aspect of a popup is rich content.  For  
> text only, use a label.  Although in your case, a formatted project  
> description qualifies as rich content IMO at least due to it's  
> sheer size (can't see how you could burn in a 3-paragraph long label).
>
> Now, the hyperlink is needed in a popup (or is it; I guess you  
> could just set it to void() ??).  I see this well in terms of  
> *content* (managed by Plone), where an hyperlink to some content  
> artifact or representation can be used.  But the popup can't point  
> back to a shapefile, so in this case you'd basically want  
> "[potentially] rich-content labels with visibility turned off by  
> default".
>
>
>> Regarding overlib popups all over the place, we could have a flag to
>> enable/disable popups for a layer and an additional field to  
>> specify the
>> (dbf or PostGIS) field  to display in the popup. At any time, only  
>> one
>> popup shows over the map.
>
> I think a key in usability would be for the user to be able to  
> explicitly tell PrimaGIS *not* to query the layers for attribute  
> info.  For the moment, you have as many "popable info layers" as  
> there are PrimaGISDataLayers in your map.  It could be useful to  
> explicitly turn the pop up machinery off for any subset of  
> DataLayers.  Maybe a "pan/zoom mode" could automatically toggle  
> popups off so that they don't interfere with panning/zooming and  
> don't make costly spatial db queries for attribute values ?  Then  
> an "info mode" would toggle popup behaviour back on (e.g. tick all  
> 'enable popups' checkboxes for DataLayers) and the user would have  
> the opportunity to further deselect some layers to turn popup off.
>
> I suspect this would involve quite a bit of machinery, especially  
> if one wanted to pass that behaviour along to "read-only"  
> PrimaGISLayer objects which is the point you're making.  If you'd  
> hyperlink to the project url, you'd need a map object (icon,  
> sensitive polygon ...) that you can attach a url to.  In effect,  
> that would mean that PrimaGIS be able to dynamically generate some  
> map object that it can link a url to from data coming from an  
> arbitrary datastore (shapefile, postGIS ...).  I still don't know  
> what url you would assign to it, but in your case the url field  
> could be used.  This is not the general case though and maybe a  
> default could be a popup with a void() hyperlink.
>
> Having the possibility to select attributes to display would mean  
> querying some resource (a shapefile, postGIS tables, WMS service)  
> with some sort of GetAttributes function that would return a list  
> of fields.  Implementation code to gather the info from within the  
> datastores would need to be written.
>

Such info already exists. Try the info method of any datastore, like

   http://zcologia.org/zco/examples/demo_mb/data/fort_collins/info


>
>> I see your point about having 10 layers in a map where a mouseover  
>> would
>> come up at every mouse movement. But that's fine. I don't think  
>> one would > use the mouseovers to substitute queries over the data  
>> in the map. They
>> would have to be used carefully by whoever is making the map.
>
> Which is another reason to be able to explicitly toggle off  
> attribute-fetch behaviour IMO.
>
> That's it for now.
>
> Cheers,
>
> Yves

I'm very interested in improving the querying features of ZCO and  
PrimaGIS. It used to be that web map querying sucked. If you were a  
MapServer user you'd click on the map and then get a new page back  
(new window or not) that held the results. These days, we know a  
better way is to make an asynchronous request and then insert the  
results into your your app. We can even mimic imagemaps like this,  
although there is increased latency and slower response.

Vaishal, what you're looking for is quite reasonable to me. But it  
also seems to me that your projects are great candidates to become  
Plone content. Maybe a Plone folder for each project, with all sorts  
of documents, images, what-not, and then attach a geometry to each  
folder. I think this is within the capabilities of PrimaGIS now.

cheers,
Sean

---
Sean Gillies
sgillies at frii dot com
http://zcologia.com/news