On Tue, Nov 5, 2013 at 2:23 PM, Martin Koppenhöfer
wrote:
> Do you mean borders are a problem in general, or are there specific
> problems related to specific borders like those mentioned in this thread?
>
I was responding to the thread. Sorry for the confusion
--
Clifford
OpenStreetMap: Maps
If someone thinks borders should be in a different database, they should
just make the database. If that is the superior solution, data consumers
will pick it up and start using that one over the existing one. I think
having a few parallel databases would make a nice little ecosystem.
Janko
__
Am 05.11.2013 um 22:56 schrieb Clifford Snow :
> If we agree that borders are a problem, then what is the best solution?
Do you mean borders are a problem in general, or are there specific problems
related to specific borders like those mentioned in this thread?
> I'd argue that the GIS co
On Tue, Nov 5, 2013 at 12:22 PM, Simon Poole wrote:
> - I do not see how filters in editors do anything more to this issue
> than make it worse, particularly in the case when the border has been
> merged with an other object. Do you make the object immutable? Or do you
> simply hide the fact that
Am 05.11.2013 um 21:29 schrieb Christoph Hormann :
> It is also important to keep in mind that in case of borders
> authoritively defined through discrete points an officially released
> data set does not necessarily represent exactly this definition.
And sometimes "official" or "authoritive
2013/11/5 Simon Poole
>
> Two remarks:
>
> - I do not see how filters in editors do anything more to this issue
> than make it worse, particularly in the case when the border has been
> merged with an other object. Do you make the object immutable? Or do you
> simply hide the fact that you are no
On Tuesday 05 November 2013, Toby Murray wrote:
> [...] The
> part of the river that is not in the lake changed course during a
> massive flood in the 1950s but the border still follows the original
> course of the river. Maybe the different handling of borders
> following a natural feature is anot
Two remarks:
- I believe that the border matches geographic features is a bit of a
red herring. There are all kinds of different practices over the world
(here for example the borders are very very often drawn not to coincide
with roads, and will run parallel to them at some distance to avoid
fig
* Paul Johnson [2013-11-05 09:18 -0600]:
> On Tue, Nov 5, 2013 at 8:05 AM, Janko Mihelić wrote:
> > The problem is, some admin borders are supposed to be glued to roads or
> > rivers, and they change when the flow of a road or river changes. How do
> > you deal with that?
>
> Well, historically,
2013/11/5 Toby Murray
> I think the reason for this is because we imported these borders a few
> years ago. Because the import process wasn't perfect, it created duplicate
> nodes wherever a border intersected a TIGER road even if there would
> normally be no reason for a node to exist on either
So it seems like the "get admin boundaries out of core OSM" opinion has
fairly decent support in the US but maybe not elsewhere. I think the reason
for this is because we imported these borders a few years ago. Because the
import process wasn't perfect, it created duplicate nodes wherever a border
On Tue, Nov 5, 2013 at 8:05 AM, Janko Mihelić wrote:
> The problem is, some admin borders are supposed to be glued to roads or
> rivers, and they change when the flow of a road or river changes. How do
> you deal with that?
Well, historically, the border doesn't move. This has caused an on-goi
I'm agree with most of the others that removing the buondaries out isn't a
good approach to solve current problems. I am agains layering in general,
as this will only lead to more inconsistencies, in the end, most if not all
stuff is somehow interlinked directly or indirectly. Even underground line
Admin boundaries can also be seen, and surveyed, where the tarmac changes.
Phil (trigpoint)
--
Sent from my Nokia N9
On 05/11/2013 14:37 Christoph Hormann wrote:
On Tuesday 05 November 2013, Jochen Topf wrote:
> [...] And it is
> totally unclear how things that are supposed to be changed toge
On Tue, Nov 5, 2013 at 3:05 PM, Janko Mihelić wrote:
> The problem is, some admin borders are supposed to be glued to roads or
> rivers, and they change when the flow of a road or river changes. How do you
> deal with that?
Like in real world. In my country, when the road or the river is
changin
On Tuesday 05 November 2013, Jochen Topf wrote:
> [...] And it is
> totally unclear how things that are supposed to be changed together
> (think borders following a river or road) are to be handled.
And in principle the OSM data strctures are quite good for this, you can
have a way with waterway=
Hi Richard,
In my opinion, changing the back end (which would be ton of work), is
probably not the best way of addressing the issues you are seeing.
We are still dealing with the hangover from the batch poorly done
imports in 2009 and 2010.
We also have an editor issue.
A better approach would b
2013/11/5 Richard Welty
> combined with
> the fact that it will be impossible to glue border
> nodes to other features, will probably address 98 or
> 99% of the issues we see today.
>
The problem is, some admin borders are supposed to be glued to roads or
rivers, and they change when the flow o
So we have bad data in OSM and you want to fix it by making it harder to
correct. Somehow I don't follow your argument... :-)
While I do agree that it would be nice to have some kind of "layering" feature
that allows us to aggregate date from different databases, this is a huge
undertaking. It is
Hi Richard,
On Tue, Nov 05, 2013 at 08:17:35AM -0500, Richard Welty wrote:
> there is an argument that some make that because
> borders are usually not easily verifiable on the ground,
> they don't belong in OSM at all. i'm somewhat sympathetic
> with the argument, but i also think that we have a
i brought up the subject of admin borders in the US over
on talk-us and there was a lot of useful discussion. i think
folks are mostly clear on the issues and tradeoffs, so i'd
like to float a proposal for an evolved approach. i'm moving
the discussion here because it's not just a US thing.
basica
21 matches
Mail list logo
