Hi,
Do you think this proposal and the Water Network one could be merged ?
https://wiki.openstreetmap.org/wiki/Proposed_features/water_network
It would be great to have a complete and consistent tagging model for water
facilities including drinking water point and reservoirs.
Let me know if peop
2014-04-03 3:39 GMT+02:00 Dave Swarthout :
> It's difficult to come up with a scheme that handles all the possibilities
> especially if you consider the reality that most tag information will never
> show up on a standard map.
well, you won't get them on a paper map most probably, but digital m
2014-04-03 1:53 GMT+02:00 Janko Mihelić :
> Rationale in the Wiki says this would save us database space, we would
> have 2 ways and 1 node less per bridge. Also, that maintaining one node is
> easier than maintaining 3 ways. Lastly, problem of pretending you have
> drawn a little bridge precise,
Whilst I think this is a very bad idea for the same reasons as already given by
Martin and Janko.
What on earth is a Brunnel? I don't know and neither does google. I have an
idea from reading the thread but I wonder how many have ignored the thread
through the choice of words in the title?
Phi
2014-04-03 11:12 GMT+02:00 Martin Koppenhoefer :
>
> FWIW, it is not true, we would "save" 1 way or 2, but the amount of nodes
> would remain the same, because with the new proposal the waterway would get
> an extra node which it hasn't otherwise. The 1 way saved is on the other
> hand loss of in
On 02/04/2014 17:14, Richard Z. wrote:
as explained in the rationale the dimensions of the bridge/culvert are
frequently only a fraction of the achievable precision. Think of a
track crossing a small creek in a forest valley int the mountains. The
GPS precision will be 10 meters if you are luck
Mike
We should be mapping as accurately as we can within the limitations (gps
accuracy, aerial imagery etc) that we have. Data can always be upgraded
when more accurate information becomes available. This proposal is a
step backwards towards inaccuracy.
On 02/04/2014 18:29, Mike Thompson wr
On 03.04.2014 01:13, Andy Mabbett wrote:
> On 2 April 2014 18:37, Tobias Knerr wrote:
>> On 02.04.2014 19:25, Andy Mabbett wrote:
>
>> The response probably refers to the fact
>> that, unfortunately, very few business websites offer contact data in a
>> machine-readable format.
>
> Perhaps, thou
Some parts are still valid and not off topic.
As material:wikidata shows that we need to well define the usage of
*:wikidata.
On the other hand we already the wiki as data base for tags and their
values. So if we stay with material or surface adding link to wikidata
in the value description would
On 03.04.2014 10:26, François Lacombe wrote:
> Do you think this proposal and the Water Network one could be merged ?
> https://wiki.openstreetmap.org/wiki/Proposed_features/water_network
Seems to me that this page needs some clean up.
* please use boundary=protected_area
* What key or value do
ATM on the german mailing list noexit=yes is discussed.
On user pointed out that on the english wiki page it is defined for
nodes and ways where as on the german one it is only valid for nodes.
I had a look at the history of the page and found some actions 3 years
ago. First it was only defined f
ATM on the german mailing list noexit=yes is discussed.
On user pointed out that on the english wiki page it is defined for
nodes and ways where as on the german one it is only valid for nodes.
I had a look at the history of the page and found some actions 3 years
ago. First it was only defined f
On Thu, Apr 3, 2014 at 4:17 PM, fly wrote:
> Is noexit=yes useful on ways ?
The way has one side that has/is an exit :-)
Tagging the whole way as "noexit=yes" seems strange.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap
fly wrote:
Is noexit=yes useful on ways ?
Asking a slightly broader question, in what situations is "noexit=yes"
useful at all, except as a cue to subsequent mappers in the very rare
situation that one way ends very close to another one and there's
absolutely nothing (not a wall, footpath,
> in what situations is "noexit=yes" useful at all, except as a cue to
> subsequent mappers in the very rare situation that one way ends very close
> to another one and there's absolutely nothing (not a wall, footpath,
> anything) between them?
>
It might be useful when there is limited visibility
On Wed, Apr 02, 2014 at 08:18:12PM +0200, Frederik Ramm wrote:
> Problem is that while "wanting things to show on the map" is a strong
> motivator for people, it doesn't scale - we are not far from the point
> where for every feature we add to our main map we have to remove another
> feature from
On 03.04.2014 21:30, John Packer wrote:
>
> in what situations is "noexit=yes" useful at all, except as a cue to
> subsequent mappers in the very rare situation that one way ends very
> close to another one and there's absolutely nothing (not a wall,
> footpath, anything) between t
On Thu, Apr 03, 2014 at 06:08:46PM +0100, Dave F. wrote:
> On 02/04/2014 17:14, Richard Z. wrote:
> >as explained in the rationale the dimensions of the bridge/culvert
> >are frequently only a fraction of the achievable precision. Think
> >of a track crossing a small creek in a forest valley int th
> Am 03/apr/2014 um 21:22 schrieb SomeoneElse :
>
> and there's absolutely nothing (not a wall, footpath, anything) between them?
you could still map that as natural=void ;-)
Seriously, there will always be something (guard rail, ditch, scrub, grass,
fence, gate, )
__
Hello,
Am 03.04.2014 21:22, schrieb SomeoneElse:
fly wrote:
Is noexit=yes useful on ways ?
Asking a slightly broader question, in what situations is "noexit=yes"
useful at all, except as a cue to subsequent mappers in the very rare
situation that one way ends very close to another one and
> Am 03/apr/2014 um 21:43 schrieb Richard Z :
>
> so again: *** <> ***
>
> Where is your aerial imagery? I want that!!
you don't need imagery, you simply draw a segment with the approx. length of
the bridge. If you have no reliable sources, putting a node won't make this
more accurate n
On Thu, Apr 03, 2014 at 01:53:15AM +0200, Janko Mihelić wrote:
> Also -1 for the proposal.
>
> Rationale in the Wiki says this would save us database space, we would have
> 2 ways and 1 node less per bridge. Also, that maintaining one node is
> easier than maintaining 3 ways. Lastly, problem of pr
On Wed, Apr 02, 2014 at 07:44:40PM +0200, Tobias Knerr wrote:
> On 02.04.2014 18:14, Richard Z. wrote:
> > On Wed, Apr 02, 2014 at 05:59:40PM +0200, Martin Koppenhoefer wrote:
> >> IMHO there is a fundamental problem to your proposal because you want to
> >> connect 2 ways with a node which are in
On Thu, Apr 03, 2014 at 09:52:13PM +0200, Martin Koppenhoefer wrote:
>
>
> > Am 03/apr/2014 um 21:43 schrieb Richard Z :
> >
> > so again: *** <> ***
> >
> > Where is your aerial imagery? I want that!!
>
>
> you don't need imagery, you simply draw a segment with the approx. length of
> t
On Thu, Apr 03, 2014 at 09:53:44AM +, Philip Barnes wrote:
> Whilst I think this is a very bad idea for the same reasons as already given
> by Martin and Janko.
>
> What on earth is a Brunnel? I don't know and neither does google. I have an
> idea from reading the thread but I wonder how man
Yes, one reason to reject this is that it involves a neologism, coined by the
proposal author, that few people will recognize and use.
On April 3, 2014 4:53:44 AM CDT, Philip Barnes wrote:
> Whilst I think this is a very bad idea for the same reasons as already
> given by Martin and Janko.
>
>
Thu, Apr 03, 2014 at 12:07:42PM +0200, Janko Mihelić wrote:
> 2014-04-03 11:12 GMT+02:00 Martin Koppenhoefer :
>
> >
> > FWIW, it is not true, we would "save" 1 way or 2, but the amount of nodes
> > would remain the same, because with the new proposal the waterway would get
> > an extra node whi
That is my main objection as well. This proposal is to deliberately reduce the
accuracy of the data in the name of saving a few seconds of mapping time.
On April 3, 2014 12:25:46 PM CDT, "Dave F." wrote:
> Mike
>
> We should be mapping as accurately as we can within the limitations
> (gps
>
On 03/04/2014 22:04, Richard Z. wrote:
A brunnel is a crossbreed of a bridge with a tunnel. It has been used somewhere
to describe
constructions where it is not easy to decide whether a grade separated crossing
is better
described as a tunnel under a road or bridge above something.
Really? A
On 03/04/2014 22:05, John F. Eldredge wrote:
Yes, one reason to reject this is that it involves a neologism, coined by the
proposal author, that few people will recognize and use.
I think he's getting confused with I.K. Brunel ;-)
Dave F.
---
This email is free from viruses and malware becau
On Thu, Apr 03, 2014 at 04:27:57PM -0500, John F. Eldredge wrote:
> That is my main objection as well. This proposal is to deliberately reduce
> the accuracy of the data in the name of saving a few seconds of mapping time.
nonsense. This proposal is here to improve the accuracy. You do not have
On Thu, Apr 03, 2014 at 10:49:56PM +0100, Dave F. wrote:
> On 03/04/2014 22:04, Richard Z. wrote:
> >
> >A brunnel is a crossbreed of a bridge with a tunnel. It has been used
> >somewhere to describe
> >constructions where it is not easy to decide whether a grade separated
> >crossing is better
>
On 03/04/2014 22:58, Richard Z. wrote:
On Thu, Apr 03, 2014 at 04:27:57PM -0500, John F. Eldredge wrote:
That is my main objection as well. This proposal is to deliberately reduce the
accuracy of the data in the name of saving a few seconds of mapping time.
nonsense. This proposal is here to
On 03/04/2014 23:06, Richard Z. wrote:
On Thu, Apr 03, 2014 at 10:49:56PM +0100, Dave F. wrote:
On 03/04/2014 22:04, Richard Z. wrote:
A brunnel is a crossbreed of a bridge with a tunnel. It has been used somewhere
to describe
constructions where it is not easy to decide whether a grade separa
On 4/3/14 6:06 PM, Richard Z. wrote:
> On Thu, Apr 03, 2014 at 10:49:56PM +0100, Dave F. wrote:
>>
>> Really? Are you sure you're not just making this up?
>>
>> Show us where or I'm calling you a fibber.
> How much more stupid do you want to get if you don't use the basic
> search function.
>
> htt
On 03/04/14 23:27, Richard Welty wrote:
On 4/3/14 6:06 PM, Richard Z. wrote:
http://wiki.openstreetmap.org/wiki/Advanced_relationships
http://wiki.openstreetmap.org/wiki/Key:layer
umm, the term only seems to appear here. google does not
find any references to it. from this i have to assume t
Am 03.04.2014 21:43, schrieb Richard Z:
On Thu, Apr 03, 2014 at 06:08:46PM +0100, Dave F. wrote:
On 02/04/2014 17:14, Richard Z. wrote:
as explained in the rationale the dimensions of the bridge/culvert
are frequently only a fraction of the achievable precision. Think
of a track crossing a smal
37 matches
Mail list logo
