You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A well normalized set of tables should have one single source of information. Unfortunately, the meta_history table has both numeric lat/lon attributes in addition to a PostGIS geometry object. This has sown confusion, in that data managers tend to forget to update the geometry object:
crmp=>selectcount(*) from meta_history where the_geom is NULLand (lat is not nulland lon is not null);
count
-------183
(1 row)
Yes, that would be me for sure -- in many places, including the frontends, which will also need to be updated. It was not clear to me what the use (or reliability) of geometry was, and all existing code I encountered did not use it.
Therefore I add the following much broader suggestion: Document table columns better. Their names alone are frequently not sufficient. Let's look into whether that documentation can be part of the SQLAlchemy column definition so that it makes it into the database proper as well. See #200
A well normalized set of tables should have one single source of information. Unfortunately, the
meta_history
table has both numeric lat/lon attributes in addition to a PostGISgeometry
object. This has sown confusion, in that data managers tend to forget to update thegeometry
object:And even our own developer have used lat/lon instead of the
geometry
.lat
andlon
should be removed.The text was updated successfully, but these errors were encountered: