Opened 14 years ago
Closed 14 years ago
#329 closed enhancement (fixed)
Improve formatting for GEOSisValidReason_r
Reported by: | Mike Taves | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 3.2.1 |
Component: | Default | Version: | 3.2.0 |
Severity: | Unassigned | Keywords: | |
Cc: |
Description
A message from PostGIS's ST_IsValidReason(geometry) shows the message:
Self-intersection[523991 6.5222e+06]
to describe a point with Easting/Northing coordinates. What I find odd is the mixed conventional numeric and exponential forms.
I can't find the source code for this, but I'm certain there is a "%g %g" formatting code somewhere in there. Although %g is usually a nice formatter, it is unfortunate that it happens to change to exponential form at numbers >=1e+06, which is the range of many projected (i.e., UTM) coordinates (particularly northern ones). [Note, this is probably compiler/platform dependent.]
To make consistent formatting of these coordinates across platforms, and to make it show projected coordinates nicely, I suggest using the formatting code: "%.7g %.7g"
This will use exponential form for numbers >=1e+07, which most earth-based Easting/Northing coordinates fall within.
Change History (7)
comment:1 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Ah, that's why I couldn't find it. I had a few bad hints to lead me to think it was a GEOS issue:
- The NEWS item "IsValidReason added to CAPI" for GEOS 3.1.0
- "
elog(ERROR,"GEOS isvalidreason() threw an error!");
" in PostGIS's lwgeom_geos.c
I'm not sure if these were mixups between projects or what.
comment:3 by , 14 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Summary: | Improve formatting for IsValidReason → Improve formatting for GEOSisValidReason_r |
It *is* a mix of the two, as PostGIS's ST_isValid* functions all use GEOS internally. What I was pointing out is that a string for a point is not the best thing to have in return..
Anyway yes, your report is actually valid I guess, so I reopen.
comment:4 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
But still.. why fix when there's a better alternative ? :) (GEOSIsValidDetail_r)
comment:5 by , 14 years ago
Milestone: | → 3.2.1 |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
It's not in PostGIS, actually, it's in GEOS. PostGIS just consumes the string produced by GEOS.
http://trac.osgeo.org/geos/browser/trunk/capi/geos_ts_c.cpp#L607
comment:6 by , 14 years ago
FYI, the alternative I'm talking about is ST_IsValidDetail, which returns a Geometry object for the location.
comment:7 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
ST_isValidReason is a PostGIS function, not GEOS... should file the ticket in there.
Look, I've good news for you: http://trac.osgeo.org/postgis/changeset/5204