[postgis-users] Request for ideas to enhance the geometry viewer - GSoC

Tue Jan 29 21:26:06 PST 2019

It's a touchy area the DB  tool should have strong DB and light on visualization – so Db work is always front and center and GIS to the side. The GIS should be lighter on DB and stronger on visualization (or at least have visualization up front).

What is light but not too light is a big fuzzy area.  So I think of it in terms of 3 users.

Leo – He likes OpenJump, cause all he wants to do is write SQL statements – hates QGIS.  Why he hates QGIS? – the only thing he wants is to be able to write a query and see it and layer queries. 

Maybe some styling to distinguish his queries when he overlays. Downside of OpenJump is inability to browse his tables and make structural changes.

QGIS forces him to open this huge GIS System -> go to DbManager. He finds it cluttered. He is NOT a GIS person so all those goodies are lost on him. He finds them to be an eyesore and weighing him down from his primary objective.

GIS person or general user – I give them QGIS they love it – they are immersed in the whole visualization thing and just want to filter their data, they go hog wild installing plugins. I try to show them the DbManager piece (the colorcoding of queries, the light intellisense, the ability to browse tables etc) (the feature I like most about QGIS), and they yawn and are totally not interested.

Me – I don't often care to visualize anything aside form spot checking my concave hull or convex hull or Geo Median is right, but it's hard to tell if I can't overlay on the original query without the calcs. So that's the only thing I really yearn for overlay and very minimalist styling.  So I end up jumping to whatever is closest QGIS or OpenJump. These days I often jump to QGIS cause I have users that feel "SAFE" (by SAFE I mean they are not lost in – what should I type) in it so I have to have a clue how to show them how to do things in it, but otherwise I'm probably more of an OpenJump / pgAdmin user.

From: postgis-users [mailto:postgis-users-bounces at lists.osgeo.org] On Behalf Of Martin Davis
Sent: Tuesday, January 29, 2019 9:25 PM
To: Paul Ramsey <pramsey at cleverelephant.ca>
Cc: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Subject: Re: [postgis-users] Request for ideas to enhance the geometry viewer - GSoC

Oh, i wasn't suggesting render-in-the-DB.  Just throwing out an idea about how styling metadata could be supplied to pgAdmin.  

I guess I wasn't totally clear. The suggestion is to supply dynamic queries with styling metadata on-the-fly within pgAdmin.  The metadata would *not* be persisted in the DB (well, it could be, but up to the user).  Putting the metadata right in SQL allows using all those SQL/Postgres functions we all know and love.already.

As for Paolo's objection, I can see his point.  But two rebuttles:

- Since it's free, why not put useful functionality everywhere?  :)

- actually it's not free - the cost occurs in having to learn an entirely new tool.  So if some useful extra functionality pops up in your tool of choice, that's a win

On Tue, Jan 29, 2019 at 6:11 PM Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> > wrote:

Yeah, every time I’ve thought about renderer-in-the-db I’ve come back to this. There’s nothing especially privileged about the db that makes a lot of sense for bringing rendering in-process. And boy it’s a rat hole… once you go down, you’re never coming back out.

P

On Jan 29, 2019, at 5:36 PM, Paolo Cavallini <cavallini at faunalia.it <mailto:cavallini at faunalia.it> > wrote:

Are you sure you want to reimplement what a GIS does already? Doing proper, powerful styling it's a really big task.
Sorry to jump in like this, I'm a strong advocate of open source tools also because you can reuse what is available, avoiding duplication of efforts.
Cheers.

Il 30 gennaio 2019 02:13:50 CET, Martin Davis < <mailto:mtnclimb at gmail.com> mtnclimb at gmail.com> ha scritto:

Here's an idea which might be a bit out there...  

Allow styling/labelling to be driven by columns in the displayed query.  The styling columns would have well-known names which are unlikely to conflict with data columns.  A nice pattern to follow is the SVG style names.  So e.g. styleStroke = line color, styleFill - fill color, styleStrokeWidth = line width, etc etc etc.  styleLabel would be the string to label with.

This allows styling to be data-driven and easily captured and shared.  

On Mon, Jan 28, 2019 at 8:16 PM Victoria Rautenbach < <mailto:victoria.rautenbach at gmail.com> victoria.rautenbach at gmail.com> wrote:

Dear PostGIS devs and users

Firstly, we (Frikan, Xuri and I) would like to thank the PostGIS
community again for the support you provided us in 2018 during Google
Summer of Code (GSoC). We truly appreciate your time and effort.

The call for OSGeo GSoC ideas is now out [1]. Frikan and I would like
to suggest a project to address some of the issues left in the
geometry viewer (available in pgAdmin4), but also include some new
functionality.

Are there any ideas or suggestions from you, the PostGIS community,
for extra functionalities that would improve the usefulness of the
geometry viewer?

Thank you in advance.

Regards
Victoria

[1]  <https://lists.osgeo.org/pipermail/soc/2019-January/004200.html> https://lists.osgeo.org/pipermail/soc/2019-January/004200.html
_______________________________________________
postgis-users mailing list
 <mailto:postgis-users at lists.osgeo.org> postgis-users at lists.osgeo.org
 <https://lists.osgeo.org/mailman/listinfo/postgis-users> https://lists.osgeo.org/mailman/listinfo/postgis-users

-- 
Sorry for being short_______________________________________________
postgis-users mailing list
 <mailto:postgis-users at lists.osgeo.org> postgis-users at lists.osgeo.org
 <https://lists.osgeo.org/mailman/listinfo/postgis-users> https://lists.osgeo.org/mailman/listinfo/postgis-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20190130/d37399b9/attachment.html>