Motion: Vote on FDO RFC 38 - SHP multi-polygons

[Orest Halustchak]

Some javascript/style in this post has been disabled (why?)

Hi,

 

There were no further comments on this RFC: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

 

I would like to motion a vote to accept this RFC.

 

Thanks,

Orest.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Orest Halustchak
Sent: Thursday, August 27, 2009 4:50 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Back to FDO RFC 38 - SHP multi-polygons

 

Hi,

 

Regarding: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

 

In our last discussions on this RFC, there was concern about performance impact.

 

Dan has done some prototype performance testing to determine the impact of this proposed change. He used some datasets that included complex multi-polygons including Norway data and Australia data that had detailed multi-polygons for all the islands (100’s of loops for each feature). Following are some statistics with before and after timings. With each of these datasets, the time to render on the screen was much longer than these load times and there is no difference that an end user would see in these cases.

 

Australia: 9 multipolygon features with 3 of them having between 800 and 900 polygon loops each, others averaging about 100 loops each.

      .015 seconds to .125 seconds

Europe: 54 multipolygon features with Norway having 862 loops, with others of 653, 509, 359 loops, and the rest averaging about 100 loops each.

      .016 seconds to .17 seconds

Queensland parcels: 2,000,000 polygons

      Unchanged at 1.6 seconds

 

So, yes it takes longer to process, but the overall timings are still sub-second for the complex cases. There is also no impact on cases of regular polygons.

 

Dan will be back from his vacation soon and will be able to do the implementation. So, I’d like to get to a vote on this if nobody has objections.

 

Thanks,

Orest.

 

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Haris Kurtagic]

Some javascript/style in this post has been disabled (why?)

+1

Haris

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Orest Halustchak
Sent: Tuesday, September 08, 2009 3:33
To: FDO Internals Mail List
Subject: [fdo-internals] Motion: Vote on FDO RFC 38 - SHP multi-polygons

 

Hi,

 

There were no further comments on this RFC: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

 

I would like to motion a vote to accept this RFC.

 

Thanks,

Orest.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Orest Halustchak
Sent: Thursday, August 27, 2009 4:50 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Back to FDO RFC 38 - SHP multi-polygons

 

Hi,

 

Regarding: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

 

In our last discussions on this RFC, there was concern about performance impact.

 

Dan has done some prototype performance testing to determine the impact of this proposed change. He used some datasets that included complex multi-polygons including Norway data and Australia data that had detailed multi-polygons for all the islands (100’s of loops for each feature). Following are some statistics with before and after timings. With each of these datasets, the time to render on the screen was much longer than these load times and there is no difference that an end user would see in these cases.

 

Australia: 9 multipolygon features with 3 of them having between 800 and 900 polygon loops each, others averaging about 100 loops each.

      .015 seconds to .125 seconds

Europe: 54 multipolygon features with Norway having 862 loops, with others of 653, 509, 359 loops, and the rest averaging about 100 loops each.

      .016 seconds to .17 seconds

Queensland parcels: 2,000,000 polygons

      Unchanged at 1.6 seconds

 

So, yes it takes longer to process, but the overall timings are still sub-second for the complex cases. There is also no impact on cases of regular polygons.

 

Dan will be back from his vacation soon and will be able to do the implementation. So, I’d like to get to a vote on this if nobody has objections.

 

Thanks,

Orest.

 

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Frank Warmerdam]

> There were no further comments on this RFC:
> http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.
>
>  
>
> I would like to motion a vote to accept this RFC.

+1

---

On final review I was somewhat concerned about the comment "On input of
geometry, there is no further processing needed as the current code will
save all input loops without checking whether they are outer or inner."

There is a particular winding order expected in properly produced shapefiles.
Does the FDO SHP driver ensure proper winding order for inner and outer
rings when writing shapefiles?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Jackie Ng]

+1 Jackie

Orest Halustchak wrote:

Hi,

There were no further comments on this RFC: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

I would like to motion a vote to accept this RFC.

Thanks,
Orest.

From: [e-mail] [mailto:[e-mail]] On Behalf Of Orest Halustchak
Sent: Thursday, August 27, 2009 4:50 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Back to FDO RFC 38 - SHP multi-polygons

Hi,

Regarding: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.


In our last discussions on this RFC, there was concern about performance impact.



Dan has done some prototype performance testing to determine the impact of this proposed change. He used some datasets that included complex multi-polygons including Norway data and Australia data that had detailed multi-polygons for all the islands (100's of loops for each feature). Following are some statistics with before and after timings. With each of these datasets, the time to render on the screen was much longer than these load times and there is no difference that an end user would see in these cases.



Australia: 9 multipolygon features with 3 of them having between 800 and 900 polygon loops each, others averaging about 100 loops each.

      .015 seconds to .125 seconds

Europe: 54 multipolygon features with Norway having 862 loops, with others of 653, 509, 359 loops, and the rest averaging about 100 loops each.

      .016 seconds to .17 seconds

Queensland parcels: 2,000,000 polygons

      Unchanged at 1.6 seconds



So, yes it takes longer to process, but the overall timings are still sub-second for the complex cases. There is also no impact on cases of regular polygons.


Dan will be back from his vacation soon and will be able to do the implementation. So, I'd like to get to a vote on this if nobody has objections.

Thanks,
Orest.


_______________________________________________
fdo-internals mailing list
[e-mail]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[e-mail]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Traian Stanev]

Some javascript/style in this post has been disabled (why?)

+1 Traian

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Orest Halustchak
Sent: Monday, September 07, 2009 9:33 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Motion: Vote on FDO RFC 38 - SHP multi-polygons

 

Hi,

 

There were no further comments on this RFC: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

 

I would like to motion a vote to accept this RFC.

 

Thanks,

Orest.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Orest Halustchak
Sent: Thursday, August 27, 2009 4:50 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Back to FDO RFC 38 - SHP multi-polygons

 

Hi,

 

Regarding: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

 

In our last discussions on this RFC, there was concern about performance impact.

 

Dan has done some prototype performance testing to determine the impact of this proposed change. He used some datasets that included complex multi-polygons including Norway data and Australia data that had detailed multi-polygons for all the islands (100’s of loops for each feature). Following are some statistics with before and after timings. With each of these datasets, the time to render on the screen was much longer than these load times and there is no difference that an end user would see in these cases.

 

Australia: 9 multipolygon features with 3 of them having between 800 and 900 polygon loops each, others averaging about 100 loops each.

      .015 seconds to .125 seconds

Europe: 54 multipolygon features with Norway having 862 loops, with others of 653, 509, 359 loops, and the rest averaging about 100 loops each.

      .016 seconds to .17 seconds

Queensland parcels: 2,000,000 polygons

      Unchanged at 1.6 seconds

 

So, yes it takes longer to process, but the overall timings are still sub-second for the complex cases. There is also no impact on cases of regular polygons.

 

Dan will be back from his vacation soon and will be able to do the implementation. So, I’d like to get to a vote on this if nobody has objections.

 

Thanks,

Orest.

 

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

+1
Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jackie Ng
Sent: Tuesday, September 08, 2009 9:58 AM
To: [hidden email]
Subject: Re: [fdo-internals] Motion: Vote on FDO RFC 38 - SHP multi-polygons


+1 Jackie


Orest Halustchak wrote:

>
> Hi,
>
> There were no further comments on this RFC:
> http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.
>
> I would like to motion a vote to accept this RFC.
>
> Thanks,
> Orest.
>
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Orest
> Halustchak
> Sent: Thursday, August 27, 2009 4:50 PM
> To: FDO Internals Mail List
> Subject: [fdo-internals] Back to FDO RFC 38 - SHP multi-polygons
>
> Hi,
>
> Regarding: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support
> for SHP.
>
>
> In our last discussions on this RFC, there was concern about performance
> impact.
>
>
>
> Dan has done some prototype performance testing to determine the impact of
> this proposed change. He used some datasets that included complex
> multi-polygons including Norway data and Australia data that had detailed
> multi-polygons for all the islands (100's of loops for each feature).
> Following are some statistics with before and after timings. With each of
> these datasets, the time to render on the screen was much longer than
> these load times and there is no difference that an end user would see in
> these cases.
>
>
>
> Australia: 9 multipolygon features with 3 of them having between 800 and
> 900 polygon loops each, others averaging about 100 loops each.
>
>       .015 seconds to .125 seconds
>
> Europe: 54 multipolygon features with Norway having 862 loops, with others
> of 653, 509, 359 loops, and the rest averaging about 100 loops each.
>
>       .016 seconds to .17 seconds
>
> Queensland parcels: 2,000,000 polygons
>
>       Unchanged at 1.6 seconds
>
>
>
> So, yes it takes longer to process, but the overall timings are still
> sub-second for the complex cases. There is also no impact on cases of
> regular polygons.
>
>
> Dan will be back from his vacation soon and will be able to do the
> implementation. So, I'd like to get to a vote on this if nobody has
> objections.
>
> Thanks,
> Orest.
>
>
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>

--
View this message in context: http://n2.nabble.com/Motion-Vote-on-FDO-RFC-38-SHP-multi-polygons-tp3600390p3603435.html
Sent from the FDO Internals mailing list archive at Nabble.com.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Dan Stoica]

Hi Frank,

> Does the FDO SHP driver ensure proper winding order for inner and outer rings when writing shapefiles?

No, it doesn't. We've discussed here this issue and apparently the best way to do it is via a new capability that tells the preferred ring orientation.

But this will not solve the problem of reading existing shapes (created via FDO or not) since the orientation is not reliable.

Thanks,
Dan.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam
Sent: Tuesday, September 08, 2009 8:09 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Motion: Vote on FDO RFC 38 - SHP multi-polygons


> There were no further comments on this RFC:
> http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.
>
>  
>
> I would like to motion a vote to accept this RFC.

+1

---

On final review I was somewhat concerned about the comment "On input of
geometry, there is no further processing needed as the current code will
save all input loops without checking whether they are outer or inner."

There is a particular winding order expected in properly produced shapefiles.
Does the FDO SHP driver ensure proper winding order for inner and outer
rings when writing shapefiles?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Jason Birch]

+1 Jason

2009/9/8 Dan Stoica <[hidden email]>

Hi Frank,

> Does the FDO SHP driver ensure proper winding order for inner and outer rings when writing shapefiles?

No, it doesn't. We've discussed here this issue and apparently the best way to do it is via a new capability that tells the preferred ring orientation.

But this will not solve the problem of reading existing shapes (created via FDO or not) since the orientation is not reliable.

Thanks,
Dan.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam
Sent: Tuesday, September 08, 2009 8:09 AM
To: FDO Internals Mail List

Subject: Re: [fdo-internals] Motion: Vote on FDO RFC 38 - SHP multi-polygons


> There were no further comments on this RFC:
> http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.
>
>
>
> I would like to motion a vote to accept this RFC.

+1

---

On final review I was somewhat concerned about the comment "On input of
geometry, there is no further processing needed as the current code will
save all input loops without checking whether they are outer or inner."

There is a particular winding order expected in properly produced shapefiles.
Does the FDO SHP driver ensure proper winding order for inner and outer
rings when writing shapefiles?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Orest Halustchak]

Some javascript/style in this post has been disabled (why?)

Hi,

 

There were no negative votes on this motion.

 

This motion is adopted.

 

Thanks everyone for providing input.

 

Orest.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Orest Halustchak
Sent: Monday, September 07, 2009 9:33 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Motion: Vote on FDO RFC 38 - SHP multi-polygons

 

Hi,

 

There were no further comments on this RFC: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

 

I would like to motion a vote to accept this RFC.

 

Thanks,

Orest.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Orest Halustchak
Sent: Thursday, August 27, 2009 4:50 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Back to FDO RFC 38 - SHP multi-polygons

 

Hi,

 

Regarding: http://trac.osgeo.org/fdo/wiki/FDORfc38 - Multi-polygon support for SHP.

 

In our last discussions on this RFC, there was concern about performance impact.

 

Dan has done some prototype performance testing to determine the impact of this proposed change. He used some datasets that included complex multi-polygons including Norway data and Australia data that had detailed multi-polygons for all the islands (100’s of loops for each feature). Following are some statistics with before and after timings. With each of these datasets, the time to render on the screen was much longer than these load times and there is no difference that an end user would see in these cases.

 

Australia: 9 multipolygon features with 3 of them having between 800 and 900 polygon loops each, others averaging about 100 loops each.

      .015 seconds to .125 seconds

Europe: 54 multipolygon features with Norway having 862 loops, with others of 653, 509, 359 loops, and the rest averaging about 100 loops each.

      .016 seconds to .17 seconds

Queensland parcels: 2,000,000 polygons

      Unchanged at 1.6 seconds

 

So, yes it takes longer to process, but the overall timings are still sub-second for the complex cases. There is also no impact on cases of regular polygons.

 

Dan will be back from his vacation soon and will be able to do the implementation. So, I’d like to get to a vote on this if nobody has objections.

 

Thanks,

Orest.

 

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals