| Got it .  
 
 Thanks, 
 
 Weidong 
 
  
    
  
  
    I'm not really sure how well that would work in practice, but you're
    welcome to give it a try and see how it goes. You'd get better
    column compression but you'd have to return all the geometry type
    columns for every query. 
    
    Thanks,
     
    Emilio
    
     On 4/2/19 10:53 AM, Weidong Duan wrote: 
     
    
      
      I’m sorry , to implement the ‘GeometryCollection’
        with four-dimension lists of doubles . And the pre email is the
        implement of `Geometry` 
       
      
        
          
           
          
            
            
              
              
                 
                 
                I know the `MultiPolygon`  is implemented
                  by lists of lists of lists of double values, To
                  implement the `GeometryCollection`, I use one column
                  to store the types of
                   Point,LineString,Polygon,MultiPoint,MultiLineString,MultiPolygon,and
                  with the another six tuple to store the real  data. 
                e.g. 
                 
                 
                Type,  point_x,point_y,
linestring_x,linestring_y,polygon_x,polygon_y,multipoint_x,multipoint_y,multiLinestring_x,multilinestirng_y,multipolygon_x,multipolygon_y 
                 
                 
                Is this OK? With the extra columns to make
                  the  ` ORC is a structured data format` 
                 
                 
                Thanks for your reply, 
                 
                 
                Weidong 
                
                
                  
                    
                     
                    
                      
                      
                        Hello, 
                        
                        The main reason is that ORC is a structured data
                        format. We can model points as two double
                        columns (one for x, one for y), line strings as
                        two lists of double values, polygons as lists of
                        lists of double values, etc. However, geometry
                        and geometry collection can contain arbitrary
                        geometry classes, so they don't have a
                        consistent model. We could do something like
                        store the geometry as a single column of WKT
                        text or WKB bytes, but then you would lose a lot
                        of the benefits of using a structured file
                        format in the first place (efficient columnar
                        compression, dictionary encoding, push down
                        predicates, etc). However, if you wanted to
                        implement them anyway, you would need to add
                        appropriate readers and writers here:  https://github.com/locationtech/geomesa/tree/master/geomesa-fs/geomesa-fs-storage/geomesa-fs-storage-orc/src/main/scala/org/locationtech/geomesa/fs/storage/orc/utils
                        
                        Thanks,
                         
                        Emilio
                        
                         On 4/2/19 9:54 AM,
                          Weidong Duan wrote: 
                         
                        
                          
                          
                          
                             
                             
                            Dear All ,  
                             
                             
                                           Geomesa-FS-ORC
                               does not  support `GeometryCollection`
                              and `Geometry` types.   Could you analyze
                               the consideration  about the two types
                              not supported ? And  If I want to add the
                              two types ,  Do you have some suggestions
                              ? 
                             
                             
                             
                             
                            
                             
                             
                           
                           
                          
                          _______________________________________________
geomesa-dev mailing list
geomesa-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/geomesa-dev 
                         
                        
                      
                      _______________________________________________ 
                      geomesa-dev mailing list
                       geomesa-dev@xxxxxxxxxxxxxxxx
                      To change your delivery options, retrieve your
                      password, or unsubscribe from this list, visit
                       https://dev.locationtech.org/mailman/listinfo/geomesa-dev 
                   
                 
                
               
             
           
         
       
       
       
      
      _______________________________________________
geomesa-dev mailing list
geomesa-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/geomesa-dev 
     
    
  
_______________________________________________ geomesa-dev mailing list geomesa-dev@xxxxxxxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.locationtech.org/mailman/listinfo/geomesa-dev  
  |