On 11/11/2013 03:48 PM, Martin Koppenhoefer wrote:
>
> 2013/11/11 Jean-Marc Liotier mailto:j...@liotier.org>>
>
> Astute observers of the concept might have remarked that since GIS
> is about layers,
>
>
> A GIS is likely organized in layers, but it is not necessary. If you
> have one big d
2013/11/11 Jean-Marc Liotier
> Astute observers of the concept might have remarked that since GIS is
> about layers,
A GIS is likely organized in layers, but it is not necessary. If you have
one big database with everything in it (like OSM) you do not necessarily
have to organize your data in
On 11/11/2013 03:39 PM, Martin Koppenhoefer wrote:
>
> 2013/11/11 Jean-Marc Liotier mailto:j...@liotier.org>>
>
> Astute observers of the concept might have remarked that since GIS
> is about layers, it is therefore perfectly logical that
> post-layers OSM uses PostGIS.
>
>
> it doesn't
2013/11/11 Jean-Marc Liotier
> Astute observers of the concept might have remarked that since GIS is
> about layers, it is therefore perfectly logical that post-layers OSM uses
> PostGIS.
>
it doesn't, it uses postgres. Postgis is used for example for rendering the
mapnik map.
cheers,
Martin
_
On 11/11/2013 03:27 AM, nicholas.g.lawre...@tmr.qld.gov.au wrote:
>
> > I'd argue that the GIS community has already decided that layers
> > are the solution. QGIS, open source gis software, already handles
> > layers much like ESRI. JOSM even handles layers.
>
> > IMHO osm is post-layers ;-)
>
> T
> > 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 community has already decided that
2013/11/6 Peter Wendorff
> +1
> and I would like to combine it:
> JOSMs filtering feature is a really great starting point but it could
> be extended by a "layering filter view" which
> - defines layers by filters where one at a time can be selected for editing
> - provides a preset system to al
Am 05.11.2013 14:49, schrieb Jochen Topf:
> 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 dif
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
-0500
> From: Richard Welty
> To: Talk Openstreetmap
> Subject: [OSM-talk] Admin borders/separate database
>
> 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 tr
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
29 matches
Mail list logo
