On Tue, Oct 22, 2013 at 7:07 AM, Bryce Nesbitt wrote:
> On Mon, Oct 21, 2013 at 2:11 PM, Johan C wrote:
>
>> > Essentially what we need is the concept of layers.
>>
>
> I don't think we really need layers, but could use editors that are
> semantically aware of things like boundaries,
> and put t
On Mon, Oct 21, 2013 at 2:11 PM, Johan C wrote:
> > Essentially what we need is the concept of layers.
>
I don't think we really need layers, but could use editors that are
semantically aware of things like boundaries,
and put them in the background until needed.
---
Some boundaries effectivel
> Am 21/ott/2013 um 17:09 schrieb Clifford Snow :
>
> Introducing layers, although difficult to implement, would certainly simplify
> editing. Moving admin boundaries and land use polygons to a layer(s) would
> simplify basic editing. No more connecting roads to boundaries and land use
> edge
> Essentially what we need is the concept of layers.
Layers do have disadvantages, how to prevent data being mapped in the wrong
layer for instance. I however do see the point that mappers, especially
newbies, break administrative boundaries. If that happens a lot, it might
be easier to 'grey them
On 21 October 2013 16:41, Toby Murray wrote:
> Having edited over a thousand of them, I would not be sad to see admin
> boundaries removed from the general OSM database. I think Russ is on to
> something with his "ClosedStreetMap" concept although that is some terrible
> branding so we need anothe
Supposing I wanted to undertake a project to solve this class of
problem, either using layers or areas or something e3lse. I imagine the
project would have a number of peices, since it affects the database,
editors, rendering tools, and heaven knows what else.
On which list would we flesh out
Yes, in that small fraction of cases there would be duplication of
positional data. But in some cases where you think this is the case, it
might actually not be. My county border was defined by a river. Now part of
the river is a reservoir and the other part has shifted over time and
through floods
Thanks everyone for the feedback on the redesign effort.
Development work on the redesign is in a lull right now due to competing
priorities, but we hope to get back to it and continue refining the design
in the near future, and we'll be taking your comments here and on the pull
request into accou
On Mon, Oct 21, 2013 at 7:41 AM, Toby Murray wrote:
> Having edited over a thousand of them, I would not be sad to see admin
> boundaries removed from the general OSM database. I think Russ is on to
> something with his "ClosedStreetMap" concept although that is some terrible
> branding so we nee
It is not always possible to separate admin boundaries from real world
features. Rivers, roads or even hedges often define a boundary.
Phil (trigpoint)
--
Sent from my Nokia N9
On 21/10/2013 15:41 Toby Murray wrote:
On Mon, Oct 21, 2013 at 6:29 AM, Colin Smale wrote:
Back on topic: how do y
On Mon, Oct 21, 2013 at 6:29 AM, Colin Smale wrote:
>
> Back on topic: how do you phrase an objective rule, or at least
> well-worded guidelines, which allow admin boundaries but disallow time zone
> boundaries? I wonder where the UK ceremonial counties, fire department
> areas, national parks etc
> I'd go the other way and abolish Winter Time. ;-)
> No DST = dark summer evenings. Not nice!
> Going on topic, not sure if something like time zones
> belongs in OSM. Would it not be better to use a more
> specialised web service to look up time zones for a
> given lat/lon? I'd prefer to minim
2013/10/21 Pieren
> It was only a consensus in the group of contributors thinking that
> (which is then easy to reach a consensus).
> This remembers me similars discussions about:
> - hi-res aerial imagery coverage by huge polygons (Yahoo!)
>
agree that this is not really a datum suitable (from
Colin Smale wrote:
My point is, gut feelings aside, that it is not reasonable to single out TZ
boundaries for this deprecation.
Actually having accurate TZ boundaries in OSM is probably more important than
some of the political boundaries. The reason I've been looking into this is
simply beca
Another popular view is that these are problems for the renderer/editor,
not intrinsic issues with the data. Tag as you see fit and the
renderers/editors will catch up! The fact that coastlines are
difficult to maintain with the current toolset is not an argument to not
have them in OSM.
Back
On Mon, Oct 21, 2013 at 11:19 AM, Colin Smale wrote:
> The traditional consensus is that anyone can put anything
> in OSM
It was only a consensus in the group of contributors thinking that
(which is then easy to reach a consensus).
This remembers me similars discussions about:
- hi-res aerial ima
Nick, this can be done for admin boundaries as well. Would you advocate
removing them from OSM as well? The change to the size of the planet
file if timezones are included is absolutely microscopic in the big
scheme of things. There are clearly many shades of grey. It's a question
of where to dr
I'd go the other way and abolish Winter Time. ;-)
No DST = dark summer evenings. Not nice!
Going on topic, not sure if something like time zones belongs in OSM. Would it
not be better to use a more specialised web service to look up time zones for a
given lat/lon? I'd prefer to minimise overloa
18 matches
Mail list logo
