Opened 14 years ago

Closed 14 years ago

#329 closed enhancement (fixed)

Improve formatting for GEOSisValidReason_r

Reported by: Mike Taves Owned by: geos-devel@…
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 strk, 14 years ago

Resolution: invalid
Status: newclosed

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

comment:2 by Mike Taves, 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 strk, 14 years ago

Resolution: invalid
Status: closedreopened
Summary: Improve formatting for IsValidReasonImprove 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 strk, 14 years ago

Resolution: wontfix
Status: reopenedclosed

But still.. why fix when there's a better alternative ? :) (GEOSIsValidDetail_r)

comment:5 by pramsey, 14 years ago

Milestone: 3.2.1
Resolution: wontfix
Status: closedreopened

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 strk, 14 years ago

FYI, the alternative I'm talking about is ST_IsValidDetail, which returns a Geometry object for the location.

comment:7 by strk, 14 years ago

Resolution: fixed
Status: reopenedclosed

Committed patch giving up to 15 significant digits. r2945 in branch. r2946 in trunk.

Note: See TracTickets for help on using tickets.