Skip to main content
  • EN

I'd like to generate a map of municipalities in the northern part of The Netherlands using D3.js. Because FME 2019 now has a TopoJSON writer, I would like to build my map using a TopoJSON file. So I created a really simple workspace, with only a WFS reader, OrientationExtractor and TopoJSON writer.

The WFS URL is:

https://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?cql_filter=gemeentenaam IN ('Het Hogeland', 'Loppersum', 'Appingedam', 'Westerkwartier', 'Groningen', 'Delfzijl', 'Midden-Groningen', 'Oldambt', 'Veendam', 'Pekela', 'Westerwolde', 'Stadskanaal')

I am only interested in the feature type 'gemeenten'.

D3.js expects the winding order of polygons to adhere to the left-hand rule. I use the OrientationExtractor to make sure they all do. I verified that the orientation of all polygons is 'left_hand_rule'.

In the TopoJSON writer I specify that geometry should be reprojected to WGS 84 and that a bounding box should be added to the TopoJSON file.

0684Q00000ArEciQAF.png

 

However, when I try to visualize the TopoJSON file with D3.js I get an unexpected result: a black square.

https://bl.ocks.org/FrieseWoudloper/78283a3667c31d1575826ab17dd4bda8

The cause is the mixed winding orders (left- and right-hand) in the TopoJSON file. Why did the winding order change into right-hand rule for most of the municipalities, e.g. 'Het Hogeland' and 'Groningen', while the winding order of 'Veendam', 'Pekela' and 'Appingedam' is still left-hand rule?

When I replace the TopoJSON writer with a GeoJSON writer (with 'Convert Areas to Counterclockwise' set to 'No') and use Mapshaper.org to export the GeoJSON file to TopoJSON, everything looks fine. D3 visualizes the municipalities in the correct way:

https://bl.ocks.org/FrieseWoudloper/fa86853aecde846e3c8d945e61869f20

Is this a bug in the TopoJSON writer or did I overlook something?

Have you tried setting the ‘write bounding box’ param to “no”?

Have you tried setting the ‘write bounding box’ param to “no”?

Yes, I've tried that. It doesn't make a difference https://bl.ocks.org/FrieseWoudloper/78283a3667c31d1575826ab17dd4bda8

Have you tried setting the ‘write bounding box’ param to “no”?

I also tried encreasing the quantization parameter to 1000000, but that also didn't have any effect.

Hi @friesewoudloper,

I looked at the two TopoJSON dataset with the new TopoJSON reader in FME 2019.1, and the FME dataset seems to have the polygons drawn counterclockwise (which FME considers left-hand rule, since polygon center is on left of path), while the Mapshaper file has the polygons drawn clockwise (right-hand rule to FME).

The FME TopoJSON writer does not enforce the polygon winding order when writing, but you can control it using the Orientor transformer, with the Orientation type set to Right hand rule.

Please add the Orientor to your workspace, and test the resulting TopoJSON in your web page.

Hi @friesewoudloper,

I looked at the two TopoJSON dataset with the new TopoJSON reader in FME 2019.1, and the FME dataset seems to have the polygons drawn counterclockwise (which FME considers left-hand rule, since polygon center is on left of path), while the Mapshaper file has the polygons drawn clockwise (right-hand rule to FME).

The FME TopoJSON writer does not enforce the polygon winding order when writing, but you can control it using the Orientor transformer, with the Orientation type set to Right hand rule.

Please add the Orientor to your workspace, and test the resulting TopoJSON in your web page.

You are right! This solved my problem. Thank you!

But it also left me a little bit confused about how to interpret the right and left hand rule.

The GeoJSON 7946 specification for example states:

A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e., exterior rings are counterclockwise, and holes are clockwise.

Also, when you look at the Help for the Convert Areas to Counterclockwise parameter of the GeoJSON writer:

Convert Areas to Counterclockwise

Yes (default): Area and donut geometries will be converted to a "right-hand" orientation (that is, outer boundaries will be in a counterclockwise orientation and inner boundaries will be in a clockwise orientation).

So, I thought the right-hand rule meant counterclockwise exterior rings, but do I understand you correctly that to FME the right-hand rule means clockwise exterior rings? Why the difference?

You are right! This solved my problem. Thank you!

But it also left me a little bit confused about how to interpret the right and left hand rule.

The GeoJSON 7946 specification for example states:

A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e., exterior rings are counterclockwise, and holes are clockwise.

Also, when you look at the Help for the Convert Areas to Counterclockwise parameter of the GeoJSON writer:

Convert Areas to Counterclockwise

Yes (default): Area and donut geometries will be converted to a "right-hand" orientation (that is, outer boundaries will be in a counterclockwise orientation and inner boundaries will be in a clockwise orientation).

So, I thought the right-hand rule meant counterclockwise exterior rings, but do I understand you correctly that to FME the right-hand rule means clockwise exterior rings? Why the difference?

Hi @friesewoudloper,

When I worked for a mapping company, right hand rule referred to the center of the area being on the right as your traversed the vertices in a clockwise direction. However, some developers seem to have been taught to look at their right hand, where the fingers curve counter-clockwise.

It seems that the discipline you come from determines how you interpret the rule, and GeoJSON is on the development side.

I wonder how long it will take for digital timepieces to make 'clockwise' a meaningless description?

Hi @friesewoudloper,

When I worked for a mapping company, right hand rule referred to the center of the area being on the right as your traversed the vertices in a clockwise direction. However, some developers seem to have been taught to look at their right hand, where the fingers curve counter-clockwise.

It seems that the discipline you come from determines how you interpret the rule, and GeoJSON is on the development side.

I wonder how long it will take for digital timepieces to make 'clockwise' a meaningless description?

Hi @friesewoudloper,

I have created an enhancement request to replace all references in FME to 'right-hand rule' or 'left-hand rule' to 'clockwise' and counterclockwise', since these are not ambiguous. Thank you for pointing out the discrepancy.

Hi @friesewoudloper,

I have created an enhancement request to replace all references in FME to 'right-hand rule' or 'left-hand rule' to 'clockwise' and counterclockwise', since these are not ambiguous. Thank you for pointing out the discrepancy.

Thank you @daveatsafe! May be another enhancement would be to add the parameter Convert Areas to Clockwise in the TopoJSON writer, similar to the Convert Areas to Counterclockwise parameter in the GeoJSON writer. TopoJSON was developed by Mike Bostock, primarily for usage in D3.js. As D3.js expects the polygons to have a clockwise exterior ring, such a parameter would make sense, I think.

 

Thank you @daveatsafe! May be another enhancement would be to add the parameter Convert Areas to Clockwise in the TopoJSON writer, similar to the Convert Areas to Counterclockwise parameter in the GeoJSON writer. TopoJSON was developed by Mike Bostock, primarily for usage in D3.js. As D3.js expects the polygons to have a clockwise exterior ring, such a parameter would make sense, I think.

 

Good idea - I have created an enhancement request for that.

Reply


Community Stats

30,159
Posts
114,480
Replies
37,806
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.