- From: Peter Rushforth via GitHub <sysbot+gh@w3.org>
- Date: Mon, 19 Jul 2021 16:48:02 +0000
- To: public-sdwig@w3.org
> All would benefit from a 'web native' representation, but I think we would be heading the wrong way if we established "geofence" as the main web native geometry expression. I wasn't suggesting that. What I was saying is that the Web needs a [`<feature>`](https://maps4html.org/MapML/spec/#the-feature-element-0) element, which doesn't make sense unless there's a [`<map>`](https://maps4html.org/MapML/spec/#the-map-element-0) to draw it on. > a "geofence" is a particular kind of "feature geometry" with particular semantics. I am suggesting that geofences of all kinds could be realized through the application of a "main native geometry expression" (your term) through the [`<feature>`](https://maps4html.org/MapML/spec/#the-feature-element-0)'s [`<geometry>`](https://maps4html.org/MapML/spec/#the-geometry-element-0) when combined with appropriate client-side processing, which could be performed by the browser via an API. As a first approximation, I would say the semantics of a geofence processing could follow the Simple Features DE-9IM model via a browser-provided API. > One could also argue that a "geofence" is the bounding geometry of a particular feature: generally a feature that exists to monitor and report on movement. Or maybe any feature that the user + website deem to be worthy of such an interaction? -- GitHub Notification of comment by prushforth Please view or discuss this issue at https://github.com/w3c/sdw/issues/1268#issuecomment-882699529 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 July 2021 16:48:04 UTC