[postgis-devel] geographystyle feature request (externaltextual representation)
Malek,Christophe [CMC]
Christophe.Malek at ec.gc.ca
Fri Sep 11 07:08:03 PDT 2015
P.S. Sorry, typo, pg_restore.
-----Original Message-----
From: postgis-devel-bounces at lists.osgeo.org
[mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of
Malek,Christophe [CMC]
Sent: 09 September, 2015 18:01
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] geographystyle feature request
(externaltextual representation)
Hi Mark et. al,
Our use case is mainly for POINT geographies so their human readable
text form is relatively small (lat lon elevation). I don't really
propose using it for any of the more complex geographies/geometries
necessarily as you point out they can get quite long. However for those
geometries, I'd almost prefer to just see the words "POLYGON",
"MULTILINESTRING", etc. (and possibly at most one of their points to get
an idea of their general location) as their text representation. This
would be a tiny bit more informative as to what is stored rather than a
bunch of numbers that are only meaningful to the machine. Human readable
text representations have the advantage that you might catch things that
you might not otherwise notice when looking at raw encoded data. You can
quickly see if your values fall within the ballpark you are expecting or
in this case the type of geometries stored. Otherwise, they could be
completely off and you might not notice until someone happens to decode
them or load them up in a visualization tool.
Human readable text representations would also probably be more
consistent with other PostgreSQL data types. Dates are a good example as
I am relatively certain they are not stored the same way you see them
when you do a "select" from the command line.
Some users can indeed work with the data largely through graphical
interfaces but for our use case we will also have many users building
software and programs that use our data which means that at some point
they will have to write and test out SQL queries prior to hard coding
them into their code. In these cases, it would be nice for them to get
to work with more human readable values at that level as well.
View are indeed a workaround but I believe what I am proposing would be
more immediately useful to developers.
To be clear, I am not proposing that this "external text representation"
be used for pg_dumps. In fact, I would probably discourage dumping to
text form in general for two reasons: 1) performance and 2) precision
loss. The precision loss I refer to is due to the conversion back and
fourth between the text representation and internal binary storage
format. Try converting some reals back and fourth using pg_dump and
pg_reload a few times and I believe you will see the precision loss I'm
talking about. I believe PostGIS text representations are currently
probably lossless but judging by the behavior of the existing real
numbers I don't believe this was necessarily the intention or a
requirement for the text output for all PostgreSQL data types. PostGIS
could of course offer the option to output lossless vs. lossy forms when
outputting to text so users can decide for themselves. Maybe something
like "SET GEOGRAPHYSTYLE TO WKT", "SET GEOGRPHYSTYLE TO HUMAN_LOSSY" or
similar. It is certainly something that DBA's should be aware of.
I hope this clarifies my use case. I'd be happy to elaborate further if
anyone has questions. It is really just a human readability convenience
mechanism at the command line level that I'm proposing.
Cheers,
Chris :)
Chris Malek
christophe.malek at ec.gc.ca
Data Assimilation Informatics
Canadian Meteorological Centre
2121 Trans Canada Highway
Dorval, Quebec
H9P 1J3
-----Original Message-----
From: postgis-devel-bounces at lists.osgeo.org
[mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Mark
Cave-Ayland
Sent: 09 September, 2015 15:59
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] geographystyle feature request (external
textual representation)
On 09/09/15 18:39, Malek,Christophe [CMC] wrote:
> Hi PostGIS devs,
>
> I would like to make a feature request relating to the"external
> textual representation"of the geography data type.In short, I would
> like to request the provision ofa directlyhuman readable formas I
> believeitmay be the intention and possibly proper usage ofhaving
> the"external textual representation".
>
> Currently it appears that the geography data type is represented
> textually as something like
> "010100008000000080EB5108400000006066662E400000000000005940" which
> means little to nothing to the average human.
>
> Obviously we can run the ST_AsText function to getanothermorereadable
> column but then we have two columns:onejustfor readability and
> anotherthat users actually work withto calculate distances etc.etc.Or
> even worse, creating even more columnsfor users to work withusing
> ST_X, ST_Y, ST_Z.
>
> I would like to request that we instead be able to set the"external
> textual representation" of the geography data typeto something more
> humanfriendly such as to the output of ST_AsText.This would allow
> users tobetter understand the data while at the same time allowing
> them to work with itwithout additional conversion.
>
> It is my understanding that this has been done in Postgres for the
> date and interval data types using thecommands:
>
> "SET DATESTYLE TO ISO" etc. or
>
> "SET INTERVALSTYLE TOPOSTGRES" etc.
>
> Postgis could perhaps include somethingsimilar:
>
> "SET GEORAPHYSTYLE TO WKT", "SET GEOGRAPHYSTYLE TO POSTGIS", etc. or
> something along those linesto give users somemoreoptions.
>
> Please forgive me if there is already such a featureas I was not able
> to find it after searching both google and the postgis forums. If
> there is,then if you could please point me in the right directionand
my apologies.
>
> If there isn't, then it might be interesting to hear back if people
> would be interested in such a featureand even more interested to hear
> back if somebody else is willing to develop it.
>
> I unfortunately don't have time at the moment to implement it myself
> as I am just at the early stages of testing Postgres/Postgisand
> converting a very large dataset.But I believe such a feature might
> make Postgis an evenmore digestible option for our end usersand
possibly others.
>
> I understand there could be some precisionrelatedissues in converting
> back and forth between internal storage and WKTformat that users would
> probably need to be aware ofbut in such cases users should probably be
> using the "binary external representation" orthe usual
> geography/geometry constructors rather than "text external
> representation" for construction anyway.Effectively, the text
> representationisprobably one of the worst ones to be working with from
> a performance standpoint(due to all theextraparsing involved)so should
> bepossibly bediscouragedin generalfor anything other thanconvenience
> forhuman use anyway.
>
> Lookingforward to hearing from you,
>
> Chris
Hi Chris,
Can you explain exactly what your use case is here? Normally for any
moderately complex geometry the text output becomes so large that even
in text form you get several screens of text which is almost impossible
to read.
If you have a small number of tables then perhaps views could be a
potential solution. But then again most people will be viewing and/or
editing the data via graphical tools rather than directly in text form.
ATB,
Mark.
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
More information about the postgis-devel
mailing list