Possible to generate longitude coordinates > 180

[batpad]

trafficstars

Steps to reproduce:

Pan the map right to the "second" world by panning right past the international date line. Then add a point. The longitudinal value for the point gets set as 360 + the real longitude value. This has an additional side effect of breaking the geocoder since the geocoder sends the proximity parameter with a lon value above 180.

Expected behaviour:

It should never be possible to generate longitude values < 180 or > 180.

Possible solution (?):

Restrict the bounding box of the map to -180,180 or so?

Not sure what the best solution here is, or if there is a legitimate use-case for coordinates > 180 - if this seems like a bug, happy to make a PR.

[bhousel]

I agree @batpad - RFC7946 suggests that tools creating geojson should implement antimeridian cutting.

I guess we'd want a twofold solution:

• when creating files - prevent map from wrapping and prevent users from drawing outside range [-180,180]
• when opening files - be permissive in what we accept.. optionally clip?

[tmcw]

Might I recommend implementing this feature as an explicit option in the Meta category rather than a default behavior:

• antimeridian cutting is a should not a must - it is not an absolute requirement level in the spec
• geojson.io does not have a strong distinction between opening & creating files
• one of the core commandments has been the more verbatim the better: implementing antimeridian cutting could introduce a condition where someone only wants to modify X parts of their geometry but ends up having geojson.io silently rewrite Y unrelated parts
• there are valid reasons for antimeridian-crossing geometries, like for demonstrations that they exist, for interpolating along such lines without adding the math for multilinestrings
• geojson.io support for multilinestrings is bad, and improving it is a very large and separate task that would have to be implemented before this one in order for antimeridian cutting to not be a hassle
• the geocoder bug is a bug in the geocoder input, and should be fixed there rather than here

[bhousel]

Thanks @tmcw .. I agree with your points above.

geojson.io support for multilinestrings is bad, and improving it is a very large and separate task that would have to be implemented before this one in order for antimeridian cutting to not be a hassle

Can you say more on this? Sorry if there are known issues - still getting up to speed on the issue tracker.

My thought was to use one of the more lightweight turf.js functions to do the clipping (bboxClip?) if the user chooses that option.

[tmcw]

See the upstream issues in Leaflet.draw - geojson.io cannot edit Multilinestring/Multipolygon because of said issues.