[mapguide-trac] #1396: Feature join rendering problems (possible explanation inside...)

[MapGuide Open Source]

#1396: Feature join rendering problems (possible explanation inside...)
---------------------------------+------------------------------------------
   Reporter:  jng                |       Owner:                 
       Type:  defect             |      Status:  new            
   Priority:  high               |   Milestone:                 
  Component:  Rendering Service  |     Version:  2.2.0          
   Severity:  critical           |    Keywords:  join, rendering
External_id:                     |  
---------------------------------+------------------------------------------
Description changed by jng:

Old description:

> Attached is a sample dataset illustrating the join problem and a "fix" to
> the join problem
>
> There is a SDF feature source (LPI_Data) joined to a non-spatial SQLite
> database (Owners), both are joined via:
>
>  Name (LPI_Data) -> LAND_TAG (Owners)
>
> With Left Outer join and 1:1 cardinality.
>
> When you view the layer LAND_STATUS at initial extents, several of the
> features are white. These features are supposed to be colored
> differently. As you pan and zoom in these "white" features are rendered
> to their proper colors.
>
> When you view the layer LAND_STATUS_FIXED at initial extents, those
> "white" features are colored correctly and as you zoom in and pan around
> those features stay that way.
>
> The LAND_STATUS_FIXED is sourced from a LPI_Data_Fixed feature source
> with the same join settings to the Owners feature source.
>
> What is the difference between LPI_Data and LPI_Data_Fixed?
>
>  * LPI_Data has duplicate [Name] property values.
>  * LPI_Data_Fixed has no duplicate [Name] property values as these
> features have been merged together to form one feature (using AutoCAD
> Map)
>
> My theory is that the GWS feature reader has faulty logic with regards to
> duplicate join values from the primary side.
>
> In the case of LAND_STATUS it will stylize correctly for the first [Name]
> property value it finds, but for subsequent identical [Name] property
> values the stylization is skipped due to this faulty logic
>
> In the case of LAND_STATUS_FIXED this doesn't happen because all [Name]
> property values are unique, so this scenario never happens.
>
> Also attached is the schema report screenshot of LPI_Data, which should
> better explain what the problem is here.

New description:

 Attached is a sample dataset illustrating the join problem and a "fix" to
 the join problem

 There is a SDF feature source (LPI_Data) joined to a non-spatial SQLite
 database (Owners), both are joined via:

  Name (LPI_Data) -> LAND_TAG (Owners)

 With Left Outer join and 1:1 cardinality.

 When you view the layer LAND_STATUS at initial extents, several of the
 features are white. These features are supposed to be colored differently.
 As you pan and zoom in these "white" features are rendered to their proper
 colors and some of the colored features are "white" again.

 When you view the layer LAND_STATUS_FIXED at initial extents, those
 "white" features are colored correctly and as you zoom in and pan around
 those features stay that way.

 The LAND_STATUS_FIXED is sourced from a LPI_Data_Fixed feature source with
 the same join settings to the Owners feature source.

 What is the difference between LPI_Data and LPI_Data_Fixed?

  * LPI_Data has duplicate [Name] property values.
  * LPI_Data_Fixed has no duplicate [Name] property values as these
 features have been merged together to form one feature (using AutoCAD Map)

 My theory is that the GWS feature reader has faulty logic with regards to
 duplicate join values from the primary side.

 In the case of LAND_STATUS it will stylize correctly for the first [Name]
 property value it finds, but for subsequent identical [Name] property
 values the stylization is skipped due to this faulty logic

 In the case of LAND_STATUS_FIXED this doesn't happen because all [Name]
 property values are unique, so this scenario never happens.

 Also attached is the schema report screenshot of LPI_Data, which should
 better explain what the problem is here.

--

-- 
Ticket URL: <http://trac.osgeo.org/mapguide/ticket/1396#comment:1>
MapGuide Open Source <http://mapguide.osgeo.org/>
MapGuide Open Source Internals