[postgis-tickets] [PostGIS] #3031: "POINT EMPTY" as WKB defaults to "MULTIPOINT EMPTY" when restoring with copy and failing validation

[PostGIS]

#3031: "POINT EMPTY" as WKB defaults to "MULTIPOINT EMPTY" when restoring with
copy and failing validation
--------------------------------------------+-------------------------------
 Reporter:  jeanchristophesaville           |       Owner:  pramsey      
     Type:  defect                          |      Status:  new          
 Priority:  medium                          |   Milestone:  PostGIS 2.1.6
Component:  postgis                         |     Version:  2.1.x        
 Keywords:  POINT EMPTY , MULTIPOINT EMPTY  |  
--------------------------------------------+-------------------------------

Comment(by pramsey):

 Every type except point as a WKB representation that goes

 endian[byte] + typenumber[integer] + numpoints[integer]

 those are the patterns you're seeing for the other types. endian, type,
 and then a zero, indicating the object has zero elements or zero points

 trouble is, the wkb for point is

 endian[byte] + typenumber[integer] + x[double} + y[double]

 there's nowhere to put in the information that the point is actually empty

 our internal representation is slightly fluffier, but in order to retain
 backwards compatibility with postgis 1.x when we moved to 2.x we kept the
 same canonical representation... this allowed things like apps (mapserver,
 geoserver, fme, etc) to keep on functioning w/o changes against 2.0 which
 was great. the only problem we've had is this compromise we had to make on
 POINT EMPTY

 probably the "best" fix would be to stop creating POINT EMPTY in *any*
 eventuality and always create a MULTIPOINT EMPTY if called upon for an
 empty pointy thing

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/3031#comment:3>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.