date:20140314


Do you have any indication from when the data may be? At least roughly
pre/post licence change (pre-licence change data would naturally pose a
number of questions)?

In general attribution of OSM in the context of non-map uses is not
particularly good and hasn't been policed at the same level. We probably
need to do the same as for map and give a couple of examples of what we
would be happy with.

Simon

Am 12.03.2014 13:04, schrieb pmsg:
 Hello,
 
 last year, I discovered a strange result when searcing for a hotel
 near Rostock Seehafen at HRS.com: One suggestion is point of
 interest - Rostock Seehafen Nord (Außer Betrieb). That is the name of
 a railway station, as it was once incorrectly tagged in OpenStreetMap.
 Incorrect because außer Betrieb means no service and should never
 have been tagged as part of the name.
 
 It can easily be verified that HRS.com uses names of railway stations
 in Germany from OSM for their search. Try also Genshagener Heide,
 which was/is also tagged incorrectly in OSM. There are several more
 obvious examples of railway stations in Germany.
 
 I cannot find any credit of OpenStreetMap at HRS.com. I assume they
 are breaching the license. I did inform the company about my
 assumption on February 18th via off...@hrs.de and received no answer.
 
 What steps could be taken? It would be great if HRS.com would add
 proper attribution and pay OSMF a compensation for the license breach.
 However, I'm not sure whose rights were infringed, if any.
 
 Regards, Nils
 
 ___
 legal-talk mailing list
 legal-talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/legal-talk
 


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Russ Nelson

Paweł Paprota writes:
  Unless you protect and license your work, you *will* be exploited
  by a powerful corporation.

It is not possible for any powerful corporation to exploit
OpenStreetMap data.

That's because OpenStreetMap is not way #20101312, it is Paweł
Paprota. OpenStreetMap is not node #1511064846, it is Richard
Weait. OpenStreetMap is not relation #445288, it is Ian Dees. Etc.
Someone could take those ways, nodes, and relations and do something
with them. We would still have our own copy of them. We would still
have Paweł Paprota, Richard Weait, and Ian Dees. Nobody can take that
away from us. We cannot be exploited, because we are not the data, we
*create* the data.

It would not be difficult to change the license, because the choice of
license now lies with the OSM Foundation.

I would note that one of the potential customers of OSM data -- the
USGS -- would require that the data be in the public domain -- which
is the license[1] I have always advocated for, from the day I heard
about a potential license change. My understanding is that the license
is the only thing keeping the USGS from using, and thus contributing
to, OSM.

[1] Or distribution policy; whatever; not an interesting discussion.

--- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Russ Nelson

Alex Barth writes:
  http://www.openstreetmap.org/user/lxbarth/diary/21221

Another aspect of where the ODbL hurts us: Because we are using a
restrictive license, we cannot argue against other parties that use a
restrictive license. Look at New York State's GIS
Clearinghouse. Individuals not welcome. For-profit corporations not
welcome. OpenStreetMap users  not welcome. NY government entities?
Welcome! Non-profits? Welcome!

We can't argue against that on principle because we're just as bad.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Florian Lohoff

On Thu, Mar 13, 2014 at 10:26:23AM -0400, Alex Barth wrote:
 Hello everyone -
 
 I've been sitting on writing about the detrimental effects of
 OpenStreetMap's share-alike license (ODbL) for a while and finally decided
 to, um, share. I've been listening long to many OpenStreetMappers I respect
 a ton telling me it's not so bad and it's just what we're stuck with right
 now. But given how bad share alike is for OpenStreetMap I don't think we
 should give up for pushing for a more open license. Here's why I think
 share-alike hurts OpenStreetMap and how this keeps OpenStreetMap from
 having the full impact it could have:
 
 http://www.openstreetmap.org/user/lxbarth/diary/21221

I was in favor of dropping Share-Alike when we switched from CC-BY-SA and
all my arguments have come reality.

From how many geocoding responses to store it becomes a Database under
the Terms of the ODbL etc ... All these uncertinity harms OSM from
adoption. Using tiles is simple - Using for more advanced stuff becomes
more and more a nightmare.

Its all a matter of interpreting the license as other have stated
in this thread. I thought we were switching from CC-BY-SA because
we didnt want any interpretation anymore. It might be that under
some jurisdications the CC-BY-SA would not have hold up but it was
the declared will. So with the ODbL we have the same situation 
but only MUCH MORE complex.

And in the End - All those how fear the big bad google for taking our
work and earning money with it if we dont make it share alike - Have
you followed data contributions lately? Contributions are not coming
because people are forced to do so - but because maintainance of data
is much easier.  This has been the case for the Linux Kernel and this
is the same with the OSM Database. (Yes - there were a few litigations
concerning the GPL - but compare that to contributions of formerly
closed source drivers etc)

There was a time when Share Alike was THE only way of forcing other
to contribute. This was well before the Internet was a so widespread
and the tasks were much smaller. Since 1995 or something we have solved
this issue - I am Linux and Open Source _only_ since around that time.
2/3rds of my life i have been using and developing Open Source/Free Software
and sharing without any restrictions.
Putting a Share Alike on OSM felt like beeing back in the stone ages of
early computing - full of fear of the big corps stealing our freedom. I
thought we had left this behind.

Today maintaining the Linux Kernel or OSM without a HUGE community is a
lost fight so there is nothing to gain by taking this data _from_ the
community. Those who do this are the ones to loose, not the ones giving
away their code/data.

IMHO Share Alike is proposed by those full of fear. Instead we should
relax and try to make OSM the most useful collection of data for
everyone not just the ones beeing able to understand the ODbL. 

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Norbert Wenzel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/14/2014 12:41 AM, Michael Kugelmann wrote:
 Am 13.03.2014 15:26, schrieb Alex Barth:
 Looking forward to your comments,
 No! Stay at Share alike to avoid misuse of open data! Compare it to
 the GPL which is frequently used in OS-Sortware.

Am I correct when I say ODBL is more like LGPL than GPL? Afaik it is
ok to use OSM data without any obligations on your work, as long as
you don't mix the data. Would that be correct?

And to the topic. It might not always be easy to enforce the
share-alike clause, but I really like the fact that we have it and may
enforce it if necessary. I don't see why this should render OSM non-free.

Norbert

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTIsJeAAoJEN1BMR2v0jNa1akP/id1wZFHEc61zffZMITCsRN6
liKJprbyw8nleb6bBLPBeFAYXkSN/7voO3Xa6Jtr45kVNWSib3rc2FrsF7rFnmJl
zMjXNeIBvxyF3afPK1dNMAC1gvhenrtU2bnTKFg4Wg7KO8OgW8zhKe8pw04y8+nq
k5MivlDUAXD7A2Oowheh9RkKj+pwY0zjqG7Z+YY6L5KCqw1tGacXdt5Zu7N7EGEe
LuoxYCGLYRrUOEjZEGFKdx+u2LjqQNXhCTYujSmElyuQIszb2Njl+2wRzfkxXHYn
P4yr/UbOTnFOBNGrUw6Z1NRWN0qC9FFjtgsyMQGJwmZ+4NpMYzXS8AtO1bEZaWji
z9pq9Z2xyBJynBuSNlbKGWse7UpYjJ4xPMHP6at6qichRYe+YSIAZz1aYMPHtKhx
+LNe/pfHcpyTEwHeay8hUrzVRNwt37ETo1+YXoKi9g+vcNw3VMWerEXLlexaGMWF
wMJBNs8xRtw0Ewcuoj0A2tF8T+bwti71I3v9qNLrvaxYrId3ElrncGAXoiCq7cD6
uNt6DUr8AvhQ6a8USr5xBUW6UITpsYIO2VJ1ol/vy4f3+2/1xmkW8AQ2RbqHcJSD
jRdxbsf5wWtQ1zTUtrcb4ipjxV7J0v4PYRkc3yQEqKkgflxN7NMhb5sSKRmNZIV0
F+oPiMNUt/MxAn5TIzMu
=KvXH
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Stefan Keller

With current ODbL I'm mainly concerned about 1. small and medium
corporations as well as 2. government entities.
I'm not so concerned about big companies, especially G* exploiting
OSM (although I dislike some behaviours of G*).
So I'm in favor of CC-BY (e.g. http://creativecommons.org/licenses/by/4.0/ ).

Yours, Stefan

2014-03-14 9:48 GMT+01:00 Norbert Wenzel norbert.wenzel.li...@gmail.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 03/14/2014 12:41 AM, Michael Kugelmann wrote:
 Am 13.03.2014 15:26, schrieb Alex Barth:
 Looking forward to your comments,
 No! Stay at Share alike to avoid misuse of open data! Compare it to
 the GPL which is frequently used in OS-Sortware.

 Am I correct when I say ODBL is more like LGPL than GPL? Afaik it is
 ok to use OSM data without any obligations on your work, as long as
 you don't mix the data. Would that be correct?

 And to the topic. It might not always be easy to enforce the
 share-alike clause, but I really like the fact that we have it and may
 enforce it if necessary. I don't see why this should render OSM non-free.

 Norbert

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBAgAGBQJTIsJeAAoJEN1BMR2v0jNa1akP/id1wZFHEc61zffZMITCsRN6
 liKJprbyw8nleb6bBLPBeFAYXkSN/7voO3Xa6Jtr45kVNWSib3rc2FrsF7rFnmJl
 zMjXNeIBvxyF3afPK1dNMAC1gvhenrtU2bnTKFg4Wg7KO8OgW8zhKe8pw04y8+nq
 k5MivlDUAXD7A2Oowheh9RkKj+pwY0zjqG7Z+YY6L5KCqw1tGacXdt5Zu7N7EGEe
 LuoxYCGLYRrUOEjZEGFKdx+u2LjqQNXhCTYujSmElyuQIszb2Njl+2wRzfkxXHYn
 P4yr/UbOTnFOBNGrUw6Z1NRWN0qC9FFjtgsyMQGJwmZ+4NpMYzXS8AtO1bEZaWji
 z9pq9Z2xyBJynBuSNlbKGWse7UpYjJ4xPMHP6at6qichRYe+YSIAZz1aYMPHtKhx
 +LNe/pfHcpyTEwHeay8hUrzVRNwt37ETo1+YXoKi9g+vcNw3VMWerEXLlexaGMWF
 wMJBNs8xRtw0Ewcuoj0A2tF8T+bwti71I3v9qNLrvaxYrId3ElrncGAXoiCq7cD6
 uNt6DUr8AvhQ6a8USr5xBUW6UITpsYIO2VJ1ol/vy4f3+2/1xmkW8AQ2RbqHcJSD
 jRdxbsf5wWtQ1zTUtrcb4ipjxV7J0v4PYRkc3yQEqKkgflxN7NMhb5sSKRmNZIV0
 F+oPiMNUt/MxAn5TIzMu
 =KvXH
 -END PGP SIGNATURE-

 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Christoph Hormann

On Friday 14 March 2014, Florian Lohoff wrote:
 [...]

 Today maintaining the Linux Kernel or OSM without a HUGE community is
 a lost fight so there is nothing to gain by taking this data _from_
 the community. Those who do this are the ones to loose, not the ones
 giving away their code/data.

Actually the Linux kernel is a good example how big companies abuse free 
open products.  Most famous example is of course Google with Android 
which circumvents the weak GPLv2 share-alike provisions and contradicts 
the spirit of the GPL, namely to ensure the right to freely study, 
modify and redistribute software by locked hardware and closed source 
modules.  But there are many other examples of closed linux systems 
(like routers, nas, entertainment) that maybe release an alibi source 
package but without practical means to acutually make modifications.

 IMHO Share Alike is proposed by those full of fear.

It seems to me it is fairly damaging for the aim of abolishing 
share-alike to assume its proponents are driven by fear.  Unless you 
try to convince people through arguments you have little chance in 
changing their opinion.

Even if you manage to create a non share-alike, 'more free' OSM this 
will inevitably fail unless you convince the vast majority of the 
mappers and you cannot do that by telling them to drop their fear and 
relax.

Keep in mind what you are essentially asking mappers here is to waive 
their right to freely use improvements others make to their mapping 
work (which is - as Simon pointed out - where share-alike kicks in).  
You would need good arguments for that i think and i have not heard 
them to this point.

Note i do not have a clear position on the whole matter - as a data user 
i see clear disadvantages of share-alike and have to deal with them but 
i see no perspective to convince me, the mapper, to settle without it 
just because it would be more convenient/more profitable for me, the 
data user... ;-)

-- 
Christoph Hormann
http://www.imagico.de/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike


One thing I would like to hear about in this context of this discussion,
are examples of concrete use cases that are not happening because of
share alike and that are in general things that the community would like
to support (so not evil corp can't take the data now and keep it).
Concrete in the sense that they are uses that really would happen if
share alike would be dropped, not we can build a straw man that shows
how bad share alike is.

Example: one of the classical straw men is that government GIS offices
over the whole world would wide spread directly take OSM data and
integrate it in to their own official datasets, if you believe that, I
have a number of bridges that I would like to sell :-). The more
realistic scenario  is that difference between their data and OSM would
trigger a resurvey on their side, which is already totally OK.

Simon


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread sabas88

2014-03-14 10:58 GMT+01:00 Simon Poole si...@poole.ch:



 Example: one of the classical straw men is that government GIS offices
 over the whole world would wide spread directly take OSM data and
 integrate it in to their own official datasets, if you believe that, I
 have a number of bridges that I would like to sell :-). The more
 realistic scenario  is that difference between their data and OSM would
 trigger a resurvey on their side, which is already totally OK.


Already happening
http://wiki.openstreetmap.org/wiki/Agenzia_mobilit%C3%A0_ambiente_territorio
(sorry, it's in Italian)


 Simon



Regards,
Stefano


  ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Serge Wroclawski

Norbert,

1. Yes, it would be fair to say that ODbL is much closer to LGPL than
it is to GPL. The ODbL does not require Share-Alike merely on
combining two datasets, but only if you modify the data that's in OSM
in addition to adding your own.

2. Using GPG is good. Using GPG without MIME encapsulation is pretty
bad. http://www.phildev.net/pgp/pgp_clear_vs_mime.html#pgpmime

- Serge

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread osm

On Fri, 14 Mar 2014 10:58:57 +0100, Simon Poole si...@poole.ch wrote:

One thing I would like to hear about in this context of this
discussion, are examples of concrete use cases that are not happening
because of share alike and that are in general things that the
community would like to support (so not evil corp can't take the data
now and keep it). Concrete in the sense that they are uses that
really would happen if share alike would be dropped, not we can build
a straw man that shows how bad share alike is.
...

On the flip side of this, if share alike is so great where are the
examples of organisations contributing back to OSM because of it?
Mostly I think organisations contribute because it is in their interest
to do so (a better map makes their product better) not because the
license says they have to.

Share alike adds massive complexity to the license. This seems
indisputable to me and just puts another barrier in the way of adoption.

IMHO, share alike is just like DRM on music in that it inconveniences
legitimate uses of the data but doesn't stop the crooks who will just
rip it off anyway regardless of what the license says.

Kevin

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Martin Raifer


To throw another log into the fire: What about imports?

OSM having a share-alike licence enabled us to incorporate (and otherwise  
use) all kinds of open data sets, which may be licensed PD/CC0, CC-BY,  
CC-BY-SA or ODbL. (A lot of open government data in the EU is released  
under CC-BY or even share-alike.)


If OSM would switch to something more liberal, we would cut us off from  
potential source material: If we were going to CC-BY our database, we  
couldn't use CC-BY-SA and ODbL material any more, and if we were going all  
the way to CC0, anything other than PD/CC0 would be a no-go.


Martin

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike



Am 14.03.2014 12:43, schrieb o...@k3v.eu:
...
 On the flip side of this, if share alike is so great where are the
 examples of organisations contributing back to OSM because of it?
 Mostly I think organisations contribute because it is in their interest
 to do so (a better map makes their product better) not because the
 license says they have to.
...

Clarification: share alike does not require that you contribute back
to OSM.

What typically happens is that the companies in question send their
users to OSM to make improvements directly in OSM, which is a clear
win-win for both parties,

Simon


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Serge Wroclawski

On Fri, Mar 14, 2014 at 7:43 AM,  o...@k3v.eu wrote:

 On the flip side of this, if share alike is so great where are the
 examples of organisations contributing back to OSM because of it?

We see this already. I've spoken to companies and orgs who have said
specifically that they would not contribute to OSM if it was not
Share-Alike. No one wants to be competing against themselves in the
future.

You don't see it because it's already part of OSM, rather than something new.

- Serge

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Jukka Rahkonen

Simon Poole wrote:

 One thing I would like to hear about in this context of this discussion,
are examples of concrete use cases that are not happening because of
share alike and that are in general things that the community would like
to support (so not evil corp can't take the data now and keep it).
Concrete in the sense that they are uses that really would happen if
share alike would be dropped, not we can build a straw man that shows
how bad share alike is.

Hi Simon,

We have considered that we cannot use OpenStreetMap as a background map in
any of the applications where users are sending location aware information
back to administration. For showing existing data it would be OK but not
for gathering data from users because user could locate a place corner of
Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at
the OSM map. The interpretation of ODbL is that this location is derived
from OSM data and thus the database of the administration would become
ODbL. It could be OK in some use cases but some data are confidential and
ODbL is not an option. Therefore we do not use OSM at all. We use our own
services and Google Maps.

This is a concrete example. However, changing the interpretation of ODbL
into georeferencing locations by looking at OSM map does not yield a
derivative database would not necessarily change the situation in Finland
any more because since 2012 most raster and vector data from the National
Land Survey of Finland have been open data under attribution-only license.
Because of this using the data is simple. This has also helped OSM because
raster maps and aerial images can be utilized for digitizing and vector
data imports have started this year.

Jukka Rahkonen-




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike



Am 14.03.2014 14:17, schrieb Jukka Rahkonen:
..
 
 Hi Simon,
 
 We have considered that we cannot use OpenStreetMap as a background map in
 any of the applications where users are sending location aware information
 back to administration. For showing existing data it would be OK but not
 for gathering data from users because user could locate a place corner of
 Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at
 the OSM map. The interpretation of ODbL is that this location is derived
 from OSM data and thus the database of the administration would become
 ODbL. It could be OK in some use cases but some data are confidential and
 ODbL is not an option. Therefore we do not use OSM at all. We use our own
 services and Google Maps.

Two remarks/questions:

- is the derived data actually being publicly used?
- Off Topic: the use doesn't seem to be compatible with what is
generally known about googles ToS (naturally I assume that is just a
question of money)

Simon



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Robert Whittaker (OSM lists)

On 14 March 2014 12:01, Martin Raifer tyr@gmail.com wrote:
 OSM having a share-alike licence enabled us to incorporate (and otherwise
 use) all kinds of open data sets, which may be licensed PD/CC0, CC-BY,
 CC-BY-SA or ODbL. (A lot of open government data in the EU is released under
 CC-BY or even share-alike.)

 If OSM would switch to something more liberal, we would cut us off from
 potential source material: If we were going to CC-BY our database, we
 couldn't use CC-BY-SA and ODbL material any more, and if we were going all
 the way to CC0, anything other than PD/CC0 would be a no-go.

As I understand it, we can't import things under CC-By-SA at the
moment anyway, because the ODbL is incompatible.

But there is a very valid point there, that it's not just a matter of
asking contributors to agree to change the license, we'd need to
review all the imported data to check whether or not the licence it
was imported under is compatible with whatever license we're wanting
to change to. To this end Ithink it's somewhat unfortunate that
OSMF/LWG haven't taken a firmer line on the use of third-party data
(not just classical imports, but other manual uses of sources) to
ensure that the sources and licences they're used under are properly
documented.

A change to anything more liberal than either CC-By or ODC-By (the
attribution-only version of ODbL) would cut out most attribution
requiring imports -- crucially, this would cause vast amounts of
damage in the UK, where mappers have been using OS OpenData from the
National Mapping Agency to enhance OSM in various ways.

As for whether share-alike is a good thing, I would note that the
contribute back argument probably hasn't helped us all that much so
far -- but I think that's as much down to potential data users being
slow to accept the benefits of open data. Yes, some potential users
are being put off as a result, but I think in time positions may
change, and data owners may well come round to accepting the benefits
of open data. Also, it's not entirely clear whether allowing more
lberal uses would actually benefit the project that much.
(Particularly not if we didn't insist on attribution.) What
share-alike certainly does do is to stop companies just ripping off
our data and not giving anything back to the community.
Philosophically and practically, I think this is a very good thing.

Overall, I can see that share-alike may be currently holding back
some potential users, but it is also helping us by preventing
crowd-serfing. Since corporate and government acceptance of opendata
is currently still in its infancy, I think it would be premature to
switch to a more liberal licence at this stage. We should wait to see
how things develop, as the OpenData movement gains further traction,
and the quality of OSM relative to other offerings increases.

Robert.

-- 
Robert Whittaker

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Peter Wendorff

Hi Jukka,
although I'm curious about an answer from someone who's more competent
in the legal things, I'm not sure with your argument here.

ODBL does not require Share-Alike for produced works.
The map, even when based on OSM data is a produced work.
Therefore even if the map is based on osm data, it's not share-alike,
and any data based on the map IMHO cannot be share-alike too.

Let's assume the opposite:
- The map is a produced work and may be published on any license (more
restrictive as well as more open than ODBL), so let's assume the map is
CC-BY (without Share-Alike),
- Then from CC-BY it follows that anyone could derive other stuff from
that map without being obliged to follow any share-alike clause.

So if anyone would require data gathered on top of an osm map to be
share-alike, he's wrong (or ODBL contradicts itself in this example in
some way).
As I assume the ODBL to be checked many times, I assume yet that
therefore your implication chain to be wrong and new data collected on
top of an osm based produced work is not tainted with share-alike from ODBL.

Nevertheless I am not a lawyer, so someone else may proove me wrong If I am.

You mention Google Maps as a possible alternative to prevent this
problem. I disagree here, too. If you're talking about a substantial
amount of data derived from (or above) an OSM based map, the same would
be forbidden with google maps data, too. As the terms of service of
google state (German version):

Sofern Sie zuvor keine schriftliche Genehmigung von Google bzw. dem
Anbieter der betreffenden Inhalte erhalten haben, dürfen Sie (a) den
Inhalt weder ganz noch teilweise kopieren, übersetzen, abändern oder
abgeleitete Werke daraus erstellen

translated by me: without written permission of Google or the affected
data providers your are not allowed to copy (in parts or as a whole),
translate or modify the content or produce derived works from it.

Therefore the same as for OSM holds for any content of Google Maps, and
you probably should think about using Google as an alternative from a
legal point of view.

regards
Peter

Am 14.03.2014 14:17, schrieb Jukka Rahkonen:
 Simon Poole wrote:
 
 One thing I would like to hear about in this context of this discussion,
 are examples of concrete use cases that are not happening because of
 share alike and that are in general things that the community would like
 to support (so not evil corp can't take the data now and keep it).
 Concrete in the sense that they are uses that really would happen if
 share alike would be dropped, not we can build a straw man that shows
 how bad share alike is.
 
 Hi Simon,
 
 We have considered that we cannot use OpenStreetMap as a background map in
 any of the applications where users are sending location aware information
 back to administration. For showing existing data it would be OK but not
 for gathering data from users because user could locate a place corner of
 Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at
 the OSM map. The interpretation of ODbL is that this location is derived
 from OSM data and thus the database of the administration would become
 ODbL. It could be OK in some use cases but some data are confidential and
 ODbL is not an option. Therefore we do not use OSM at all. We use our own
 services and Google Maps.
 
 This is a concrete example. However, changing the interpretation of ODbL
 into georeferencing locations by looking at OSM map does not yield a
 derivative database would not necessarily change the situation in Finland
 any more because since 2012 most raster and vector data from the National
 Land Survey of Finland have been open data under attribution-only license.
 Because of this using the data is simple. This has also helped OSM because
 raster maps and aerial images can be utilized for digitizing and vector
 data imports have started this year.
 
 Jukka Rahkonen-
 
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Florian Lohoff


Hi,

On Fri, Mar 14, 2014 at 10:58:57AM +0100, Simon Poole wrote:
 
 One thing I would like to hear about in this context of this discussion,
 are examples of concrete use cases that are not happening because of
 share alike and that are in general things that the community would like
 to support (so not evil corp can't take the data now and keep it).
 Concrete in the sense that they are uses that really would happen if
 share alike would be dropped, not we can build a straw man that shows
 how bad share alike is.
 

I can tell on my own base. I work for a company which does FTTH/VDSL2
infrastructure operation and planning. Internally i am playing with
OSM Data mixed with other Telecoms infrastructure data - Using OSRM
to calculate infrastructure distances e.g. DSL Speeds etc., construction
costs of FTTC, FTTH projects.

Never ever that mixed infrastructure data will be available under ODbL.

Although the produced work might be interesting to detect internet white
spots i cant give it out of my Hands. So it'll stay as little toy project
of mine.

Whenever there is a need to produce stuff off my hands i'd need to buy
commercial map/geodata material. 

It a matter of fact that i'd need to pay lawyers and find complicated
ways to use OSM - So i dont.

Complex Licenses or uncertainty is enough for me to not go down that path.

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Jukka Rahkonen

Simon Poole wrote:

 Two remarks/questions:

 - is the derived data actually being publicly used?
Sometimes is, sometimes not. If it is publicly used then it may be that
only part of the attributes are public. Something that is not publicly
used right now may come public in the future but still not with all the
attributes. With the maps from the National Land Survey there is no need
to worry about all that. Unfortunately there is not yet infrastructure for
making the use of NLS maps as easy as OSM or Google and that is a trouble
for small municipalities, for example.

 - Off Topic: the use doesn't seem to be compatible with what is
generally known about googles ToS (naturally I assume that is just a
question of money)

I haven't heard about any troubles with Google's ToS and I know that
lawyers have been used for checking that. Don't know about money.

-Jukka Rahkonen-





Simon



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Hate captchas!!!!

Hi,

is there really no way to avoid those horrible captchas whenever I add
a link to a JOSM bug ticket or another friendly website to the wiki??

There are at least 2 tickets open which could help a lot:
*https://trac.openstreetmap.org/ticket/5116
*https://trac.openstreetmap.org/ticket/3898

I need on average 4 captcha-reloads before I get a captcha picture which 
I can recognise with good enough confidence to even try it.

How about an OSM quiz instead of captchas?

Richard

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Steve Coast

I disagree. This is about money; my personal belief is that CloudMade would 
have made more dollars without having to ShareAlike. More business models open 
up, and it wouldn’t have had to deal with the community. Indeed I imagine this 
was a topic of continual discussion.

The ODbL requires only two things and my understanding is that MapBox disagree 
with both of them, or at least Alex does. This shouldn’t be surprising, they 
hinder making money, like it did for CM.

But in those cases, we’re talking about competition in the market via data sets.

My personal belief, not speaking for them, is that Telenav has a different 
focus, in that free-to-the-consumer turn-by-turn navigation doesn’t have these 
impediments. Therefore it would in theory not be an issue in our case to 
attribute and ShareAlike. Like in my original slides about OSM from years ago - 
it’s about moving up the stack and competing at a higher level, not competing 
over data itself (where attribution and ShareAlike are relevant). Instead, 
going all-in on OSM and focusing on the product and user experience. Remember, 
these problems only occur if you don’t want to use OSM, but want to use it with 
other datasetsets that you don’t want to contribute back.

As for legal opinions on the ODbL you should understand that weaker (or, 
really, any) lawyers don’t like new things. New un-tested things have the 
potential to blow up in your face and throw you in court. Therefore the 
calculus is different when you are small and court is a scary place, compared 
to if you’re a big company say like Microsoft and you’re in court all the time. 
In my time I’ve met plenty of lawyers who’re fine with the ODbL and it 
shouldn’t be characterized that all lawyers everywhere somehow have major 
problems with it. The community norms (and the new ones the LWG is apparently 
putting together I heard) help very much here, and of course there are always 
issues with any license.

Whether the ODbL is good or bad for OSM is a different question. The ODbL was a 
very fun multi-year process that I happen to have been deeply involved in. It 
would be nice if there was data to suggest that one license is measurably 
better than another (for OSM). Instead, we have a large collections of 
anecdotes (not data) like “nobody uses OpenBSD because of the license” or 
“Linux wins because of the license”.

We’ve had beliefs like that in the past. For example “lots more people would 
edit with nicer tools”. This is a belief I shared. So, multiple times, we’ve 
built nicer tools. And it’s turned out that there is some small grain of truth 
to that but it’s not really comparable to the effort involved. I was wrong.

Alex makes a bunch of these statements like that, I’ll pick three that jump out:

1) the assumption that share-alike encourages contribution is a myth”
2) The reality is that OpenStreetMap is only used extensively in situations 
where the share-alike license does not apply, for instance, map rendering.
3) OpenStreetMap's current licensing is stunting our growth

And respond:

1) Data would be useful either way
2) I’d say that’s because OSM doesn’t contain a lot of address or navigation 
data (which, as it happens, is where the money is), not because of the license.
3) My personal belief is it might stunt CloudMade or MapBox, but not Telenav or 
MapQuest, and, http://wiki.openstreetmap.org/wiki/Stats doesn’t show a lot of 
evidence of being stunted.

ct.

I’ll sum by saying that when you’re picking licenses you’re really picking 
business models. We should be very careful when considering license changes and 
make sure any choice is backed by the best data we can get, not anecdotes or 
nice sounding stories. The ODbL has got us this far, and all the graphs are 
up-and-to-the-right. Exponential curves are powerful. Lastly, consider the 
weight of effort thousands of people put in to mapping before you to get us 
here, and what terms they did it under.

Steve





On Mar 14, 2014, at 1:18 AM, Russ Nelson nel...@crynwr.com wrote:
 Alex Barth writes:
 http://www.openstreetmap.org/user/lxbarth/diary/21221
 
 Another aspect of where the ODbL hurts us: Because we are using a
 restrictive license, we cannot argue against other parties that use a
 restrictive license. Look at New York State's GIS
 Clearinghouse. Individuals not welcome. For-profit corporations not
 welcome. OpenStreetMap users  not welcome. NY government entities?
 Welcome! Non-profits? Welcome!
 
 We can't argue against that on principle because we're just as bad.
 
 -- 
 --my blog is athttp://blog.russnelson.com
 Crynwr supports open source software
 521 Pleasant Valley Rd. | +1 315-600-8815
 Potsdam, NY 13676-3213  | Sheepdog   
 
 ___
 Talk-us mailing list
 talk...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-us


___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk] Hate captchas!!!!

What I saw on Tuesday seem to indicate that ReMAPTCHA (Stefan?) is
nearly here. As the name says it is map related.

Unluckily it is still a pain to use if you have problems with your
eyesight, but at least you are not working for google at the same time.

Simon


Am 14.03.2014 16:06, schrieb Richard Z.:
 Hi,
 
 is there really no way to avoid those horrible captchas whenever I add
 a link to a JOSM bug ticket or another friendly website to the wiki??
 
 There are at least 2 tickets open which could help a lot:
 *https://trac.openstreetmap.org/ticket/5116
 *https://trac.openstreetmap.org/ticket/3898
 
 I need on average 4 captcha-reloads before I get a captcha picture which 
 I can recognise with good enough confidence to even try it.
 
 How about an OSM quiz instead of captchas?
 
 Richard
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

2014-03-14 Thread colliar

On 14.03.2014 16:06, Richard Z. wrote:
 Hi,
 
 is there really no way to avoid those horrible captchas whenever I add
 a link to a JOSM bug ticket or another friendly website to the wiki??

How about interlinks ?

JOSM Trac has some for most common external website (OSM, OSM-wiki,
OSM-Trac etc.)
This is also needed to stay on the same protocol (https)


 There are at least 2 tickets open which could help a lot:
 *https://trac.openstreetmap.org/ticket/5116
 *https://trac.openstreetmap.org/ticket/3898
 
 I need on average 4 captcha-reloads before I get a captcha picture which 
 I can recognise with good enough confidence to even try it.
 
 How about an OSM quiz instead of captchas?

colliar



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

2014-03-14 Thread Tom Hughes


On 14/03/14 15:06, Richard Z. wrote:


How about an OSM quiz instead of captchas?


You're offering to write one I take it?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

On Fri, Mar 14, 2014 at 03:43:38PM +, Tom Hughes wrote:
 On 14/03/14 15:06, Richard Z. wrote:
 
 How about an OSM quiz instead of captchas?
 
 You're offering to write one I take it?

will think about one. In the short term, there are open tickets
which should make it a lot easier


Richard

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

2014-03-14 Thread Tom Hughes


On 14/03/14 15:50, Richard Z. wrote:

On Fri, Mar 14, 2014 at 03:43:38PM +, Tom Hughes wrote:

On 14/03/14 15:06, Richard Z. wrote:


How about an OSM quiz instead of captchas?


You're offering to write one I take it?


will think about one. In the short term, there are open tickets
which should make it a lot easier


Well 5116 doesn't actually specify what it is you actually the admins to 
do. It asks for known good URLs to be whitelisted without actually 
defining what constitutes a known good URL.


Since I'm pretty sure that both known good and known bad are 
infinite sets, even if anybody could agree what constituted good or bad 
in this context, it is really very helpful.


I'm sure if you make concrete suggestions for URLs that should be 
whitelisted then somebody will consider them.


I'm not exactly sure what 3898 is asking for because I'm not familiar 
with the details of that config option, but it sounds like it is just 
asking for the captcha to be switched off. I'm sure that would be lovely 
for the real wiki users. I'm equally sure it would be lovely for the 
spammers, so it's not really a solution for anything.


Certainly neither of those tickets seems to represent something trivial 
or concrete that could be actioned immediately in the way you are implying.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

2014-03-14 Thread colliar

On 14.03.2014 17:01, Tom Hughes wrote:
 On 14/03/14 15:50, Richard Z. wrote:
 On Fri, Mar 14, 2014 at 03:43:38PM +, Tom Hughes wrote:
 On 14/03/14 15:06, Richard Z. wrote:

 How about an OSM quiz instead of captchas?

 You're offering to write one I take it?

 will think about one. In the short term, there are open tickets
 which should make it a lot easier
 
 Well 5116 doesn't actually specify what it is you actually the admins to
 do. It asks for known good URLs to be whitelisted without actually
 defining what constitutes a known good URL.
 
 Since I'm pretty sure that both known good and known bad are
 infinite sets, even if anybody could agree what constituted good or bad
 in this context, it is really very helpful.
 
 I'm sure if you make concrete suggestions for URLs that should be
 whitelisted then somebody will consider them.
 
 I'm not exactly sure what 3898 is asking for because I'm not familiar
 with the details of that config option, but it sounds like it is just
 asking for the captcha to be switched off. I'm sure that would be lovely
 for the real wiki users. I'm equally sure it would be lovely for the
 spammers, so it's not really a solution for anything.
 
 Certainly neither of those tickets seems to represent something trivial
 or concrete that could be actioned immediately in the way you are implying.

How about interwiki links to *.wikipedia.org, *.openstreetmap.org and
josm.openstreetmap.de for a start ?

Could be first in the whitelist but interwiki links would be much nicer.

cu colliar



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Eugene Alvin Villar

On Fri, Mar 14, 2014 at 9:15 PM, Serge Wroclawski emac...@gmail.com wrote:

 We see this already. I've spoken to companies and orgs who have said
 specifically that they would not contribute to OSM if it was not
 Share-Alike. No one wants to be competing against themselves in the
 future.


This is actually a pretty good argument for share-alike.By having
share-alike, a company that pours time, money, and effort into improving
the database will not inadvertently help a competitor that would not give
anything back.

Sure, a CC-BY or even CC0/PD license is freer than a share-alike license,
but only for a data user in isolation (they don't have any onerous
obligations and that's freer).

But, share-alike ensures that the freedom is sustainable for *everybody* in
perpetuity and not just single users.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

2014-03-14 Thread Tobias Knerr

On 14.03.2014 17:15, Tom Hughes wrote:
 I think most of those are already whitelisted aren't they?

Unless I'm mistaken, these are the currently whitelisted URLs:
http://wiki.openstreetmap.org/wiki/MediaWiki:Captcha-addurl-whitelist

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Cristian Consonni

2014-03-13 15:26 GMT+01:00 Alex Barth a...@mapbox.com:
 I've been sitting on writing about the detrimental effects of
 OpenStreetMap's share-alike license (ODbL) for a while and finally decided
 to, um, share. I've been listening long to many OpenStreetMappers I respect
 a ton telling me it's not so bad and it's just what we're stuck with right
 now. But given how bad share alike is for OpenStreetMap I don't think we
 should give up for pushing for a more open license. Here's why I think
 share-alike hurts OpenStreetMap and how this keeps OpenStreetMap from having
 the full impact it could have:

 http://www.openstreetmap.org/user/lxbarth/diary/21221

I had a question, starting from this:
«Ever tried to get an actual lawyer to provide guidance on the ODbL?
That's what I'm talking about. Tried to use the OpenStreetMap Wiki to
learn about how the ODbL is interpreted by the licensor, the
OpenStreetMap Foundation? That's what I'm talking about.»

How many cases of litigation in court over ODbL licensed data do we
know about so far?

Cristian
An interested Wikipedian and mapper.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

On Fri, Mar 14, 2014 at 07:12:13PM +0100, Tobias Knerr wrote:
 On 14.03.2014 17:15, Tom Hughes wrote:
  I think most of those are already whitelisted aren't they?
 
 Unless I'm mistaken, these are the currently whitelisted URLs:
 http://wiki.openstreetmap.org/wiki/MediaWiki:Captcha-addurl-whitelist

great, hope that will work.

Richard

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

2014-03-14 Thread Andrew Hain

Richard Z. ricoz.osm at gmail.com writes:

 I need on average 4 captcha-reloads before I get a captcha picture which 
 I can recognise with good enough confidence to even try it.

You only have to type the right number for the distorted figures. You can
type whatever you like for the photograph.

--
Andrew


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

2014-03-14 Thread Дмитрий Киселев

Andrew, ha, as a rule, you can recognize a photo but not a distorted
figures.


2014-03-14 22:50 GMT+01:00 Andrew Hain andrewhain...@hotmail.co.uk:

 Richard Z. ricoz.osm at gmail.com writes:

  I need on average 4 captcha-reloads before I get a captcha picture which
  I can recognise with good enough confidence to even try it.

 You only have to type the right number for the distorted figures. You can
 type whatever you like for the photograph.

 --
 Andrew


 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk




-- 
Thank you for your time. Best regards.
Dmitry.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Hate captchas!!!!

2014-03-14 Thread Cristian Consonni

2014-03-14 16:19 GMT+01:00 Simon Poole si...@poole.ch:
 What I saw on Tuesday seem to indicate that ReMAPTCHA (Stefan?) is
 nearly here. As the name says it is map related.

Wonderful idea!
There's a demo/the code somewhere?

Cristian

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread moltonel 3x Combo

On 14/03/2014, o...@k3v.eu o...@k3v.eu wrote:
 On the flip side of this, if share alike is so great where are the
 examples of organisations contributing back to OSM because of it?

There's one fairly obvious to me : the share-alike requirement is
necessary to enforce the attribution requirement (otherwise any user
could just change the license to one that doesn't require
attribution). And that (c) osm visible in all the websites that use
osm, be it fousquare or my cat's blog, is a very powerfull tool to
gain recognition, users, and contributors. Without share-alike,
companies would listen to their web designers and remove the ugly and
useless attribution.

 Mostly I think organisations contribute because it is in their interest
 to do so (a better map makes their product better) not because the
 license says they have to.

The user's best interest is the carrot, but the license is the stick.
There's no harm using both, it's actually better.

I certainly hope that the carrot is the main reason why people
contribute :) But the stick has been needed many times as well.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread moltonel 3x Combo

On 14/03/2014, Jukka Rahkonen jukka.rahko...@latuviitta.fi wrote:
 For showing existing data it would be OK but not
 for gathering data from users because user could locate a place corner of
 Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at
 the OSM map. The interpretation of ODbL is that this location is derived
 from OSM data and thus the database of the administration would become
 ODbL.

To me that's a very strict/paranoiac interpretation of the odbl.
Especially if locations are looked up on a raster rendering, rather
than matched with vector data.

As it turns out, OSM itself has decided to use that paranoiac
interpretation when looking at aerial imagery for example. Because we
need to be paranoiac when using other people's data. But when other
people are using our data, we could appease their paranoia if the OSMF
released a list of interpretation for the tricky corner-cases.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

2014-03-14 Thread Toby Murray

On Mar 14, 2014 8:24 AM, Jukka Rahkonen jukka.rahko...@latuviitta.fi
wrote:

 Simon Poole wrote:

  One thing I would like to hear about in this context of this discussion,
 are examples of concrete use cases that are not happening because of
 share alike and that are in general things that the community would like
 to support (so not evil corp can't take the data now and keep it).
 Concrete in the sense that they are uses that really would happen if
 share alike would be dropped, not we can build a straw man that shows
 how bad share alike is.

 Hi Simon,

 We have considered that we cannot use OpenStreetMap as a background map in
 any of the applications where users are sending location aware information
 back to administration. For showing existing data it would be OK but not
 for gathering data from users because user could locate a place corner of
 Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at
 the OSM map. The interpretation of ODbL is that this location is derived
 from OSM data and thus the database of the administration would become
 ODbL. It could be OK in some use cases but some data are confidential and
 ODbL is not an option. Therefore we do not use OSM at all. We use our own
 services and Google Maps.

Foursquare uses OSM (and Google maps, depending on which app screen you are
in) to derive/verify venue locations.

Toby
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-nl] Postbussen

2014-03-14 Thread osm-talk-nl

Hallo!

TL;DR: Is het een goed idee om te proberen de lijst van brievenbussen van 
PostNL los te peuteren en te importeren in OSM? Ik zie dat ik brievenbussen op 
de kaart toe kan voegen, maar ik ben er nog geen enkele tegengekomen, laat 
staan compleet met lichtingsmomenten zoals ze wel op de PostNL site staan.

---

Ik ben nieuw hier dus even voorstellen: Ik ben Luc (OSM username lucb1e), doe 
een hbo ict opleiding in het zuiden van het land, en ben een open-source fan. 
OSM vind ik een interessant project en ik wil best wat meehelpen door gebieden 
die ik ken te verbeteren. Misschien dat ik ook links en rechts wat aan 
bekendheid ga doen.

Een ding wat me opviel was dat er weinig brievenbussen op de kaart staan, 
terwijl PostNL daar gewoon een database voor heeft (er is een zoekfunctie op 
hun site). Ik heb ernaar gezocht in alle uithoeken van de site, maar er lijkt 
geen (indexeerbare) lijst te zijn.

Vandaag heb ik daarom PostNL gebeld, kort uitgelegd wat OSM is, en gevraagd of 
ze een lijst van brievenbussen hebben. Meneer had deze niet, en ik werd 
geadviseerd om PostNL een verzoek per post te sturen (de ironie).

Voordat ik mijn tijd en postzegels ga verdoen aan verdere acties ben ik meer 
gaan lezen over imports, en al snel las ik dat imports soms zelfs negatief zijn 
in bepaalde gebieden en ik beter eerst de lokale community kan vragen. Dus bij 
deze: denken jullie dat het nuttig is om brievenbussen op de kaart te zetten? 
Ik vind het opzich wel leuk om te proberen om deze dataset los te krijgen, dus 
tenzij het liever niet is ga ik er waarschijnlijk mee verder. Tips zijn ook 
welkom trouwens.

Overigens, mailinglists zijn wel niet helemaal mijn ding en het is pas de 
tweede keer dat ik naar een lijst post, dus verbeter a.u.b. (netiquette) fouten 
als ik die maak!

Thanks,
Luc


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-ie] mapping roads

2014-03-14 Thread Donie Kelly

I got nothing back. Didn't follow it up. 


On 14 Mar 2014, at 19:50, Daniel Cussen d...@post.com wrote:

 I've just got a response from An Garda that my request has been passed up 
 the chain.
 Fingers crossed.
 Donie
 
 Donie Did you ever get an official response from the Gardai regarding
 your request to use the data from Gardai.ie speedzones?
 
 I am very interested in putting in this data too. If we get the
 official NO then we can begin mapping them ourselves and proactively
 seeking them out and marking them. I travel on national routes
 countrywide quite often so I could start getting the GPS positions of
 the signs on each side of the road, if we cannot use the Gardai info.
 
 So the first thing should be to get an official respose, and if it is
 yes then it should be easy to map the zones
 
 http://wiki.openstreetmap.org/wiki/Tag:highway%3Dspeed_camera
 http://wiki.openstreetmap.org/wiki/Relation:enforcement
 
 
 On 14/03/2014, Donie Kelly donie.ke...@gmail.com wrote:
 Can we add the restricted speed zones? The ones the go safe cameras are on?
 Just the speed limits on those stretches?
 
 I'm working on an app for the speed zones and I'd like to be able to pop up
 the speed limits as they are not always signed.
 
 I can statically scan for updates to release to the app when updates on the
 roads are implemented.
 
 Any objections on using the data for this?
 
 Donie
 
 On 14 Mar 2014, at 18:27, da fo43 daf...@outlook.com wrote:
 
 Hello All, First
 time posting on the mailing list but I've spoken individually to a
 number of you already. There can't be too many roads still to map in
 Ireland now so I guess the next step would be to improve the quality by
 filling in road numbers, names, etc. So I'm going to propose a few
 standards and see what people think. 1.   Map L roads 1000 to 4999
 (Local Primary) as 'Tertiary' and all other public roads as 'Unclassified'
 or 'Residential'.
 I know people have a lot of differing views on this and will admit that
 some local primary roads seem to have less importance than Local
 Secondary and Local Tertiary roads but really I think it's better to go
 with what is designated rather than making judgement calls. On some
 parts of the map all roads are being set to 'Tertiary' so really I don't
 think the current system works. All other roads are mapped as per
 designation so I personally don't see why this should be any different.
 2.   Labeling roads L1000- with spaces.
 I see on some parts of the map that roads are being labelled with a
 space 'L 1234' instead of 'L1234'. I would be in favour of sticking to
 one standard, and going with the majority in not using a space.
 3.   Labeling roads over L.
 I propose the labeling roads listed as L12341 as L1234-1 as
 this makes it easier to read and work out which branch of
 primary/secondary road it belongs to. I guess this might not suit
 everyone.
 
 4.   Non public roads to be displayed as 'Service' or 'Track' only.
 It's not always obvious if some roads are private (especially some
 housing estates) but where it is known for certain they are private then
 I would be in favour of using a 'service' road rather than
 'residential' or 'unclassified'.
 
 Hopefully
 we can agree on some things and apologies if I have overwritten
 anyone's work recently, it's certainly not my intention to do so and I
 will go with whatever the consensus is. Lastly I was planning on making
 some small updates to the Wiki page, just a general cleanup on removing
 dead links and adding a sat nav section, if anyone has any objections
 please let me know.
 
 David
 
 ___
 Talk-ie mailing list
 Talk-ie@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ie
 
 ___
 Talk-ie mailing list
 Talk-ie@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ie
 
 ___
 Talk-ie mailing list
 Talk-ie@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ie

___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

PessoALL,
 Sou do Rio de Janeiro e estou dando manutenção no OSM desde novembro de 
2013 (estou aprendendo bastante!) e vim pedir ajuda, principalmente aos 
colaboradores do Rio de Janeiro que conhecem bem os trechos que irei falar...   
  Fiquei bastante contente ao conseguir minha primeira compilação, depois de 
algumas tentativas e erros, finalmente tenho um script que roda liso. Porém, 
notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas:
Mapa RJ:
  A ponte Rio/Niterói só vai até a ilha de Mocanguê sentido Niterói/Rio e 
aparece uma outra estrada ao lado que parece ser ela.  O contorno da orla vindo 
pela Av. do Contorno está dentro d'água e vai assim por toda orla de Niterói, 
as ruas da Ilha da Conceição(Niterói) estão sobre a Baia de Guanabara.
Tracei uma rota de São Gonçalo (onde moro) até João Pessoa e para minha 
surpresa, o GPS começa a rota por uma estrada(possivelmente a BR-101) só que 
pelo meio de São Gonçalo e não pela orla (onde ela realmente passa), esta 
estrada virtual no visual fica por baixo do mapa, só aparece em alguns 
trechos.  
Mapa Brasil:
  A ponte Rio/Niterói aparentemente está correta. Porém a estrada virtual 
aparece no meio de São Gonçalo e os problemas visuais da orla, ruas dentro 
d'água continuam.


Os mapas disponíveis no projeto COCAR estão com os mesmos problemas, e o do 
site oficial do OSM tem um problemas parecido no bairro de Alcantara/São 
Gonçalo, algumas ruas não aprecem no mapa compilado (no GPS).
Obrigado pela atenção,
Hélio Coutinho.

Date: Tue, 11 Mar 2014 11:21:56 -0300
From: paulo.r.m.carva...@gmail.com
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br]  Kit para compilação Garmin em Windows e mapas Garmin 
para download

335 é o código IBGE para SP.  Na verdade 35. O 3 a mais seria região sudeste.  
Isso é para nos certificar de que não haja colisão de IDs caso o usuário 
instale mais de um mapa.  O do RJ é 333.  Mas esse código poderia ser qualquer 
um que quiséssemos inventar, desde que seja único.


Colocarei um link lá no Cocar.  Aliás tenho que fazer uma página com a relação 
de mapas, (que tende a crescer) e citar a cortesia.  Os links no menu não vão 
dar certo.

[ ]s e obrigado.   

Paulo



2014-03-11 9:43 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:

--mapid não existe

Para family-id e product-id, tem algo em específico para serem 335?



Tirando isso, o de SP está aqui:

http://naoliv.iq.unesp.br/mapas/gmapsupp.img



___

Talk-br mailing list

Talk-br@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-br




___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
  ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Why Imports in OpenStreetMap Are Controversial

2014-03-14 Thread Wille

Há um novo texto no blog do Serge sobre a dificuldade de manutenção de 
dados importados no OSM: 
http://blog.emacsen.net/blog/2014/03/13/the-maintenance-of-imported-data-in-openstreetmap/


On 04-02-2014 19:59, Wille wrote:
Compartilho um texto muito bom sobre a questão das importações no OSM: 
http://blog.emacsen.net/blog/2014/01/25/why-imports-in-openstreetmap-are-controversial/


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br



___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] São Paulo capital, tag reg

2014-03-14 Thread Marcelo Pereira

Taí uma tag que eu nunca entendi como preencher, REF

Sempre que rodo o validador do JOSM, aparecem críticas relacionadas.

E é tanta coisa colocada lá que fica dificil saber o que é mesmo para ficar.

Marcelo


2014-03-13 23:53 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:

 On Thu, Mar 13, 2014 at 11:47 PM, Erick de Oliveira Leal
 erickdeoliveiral...@gmail.com wrote:
  http://www.openstreetmap.org/way/38709823
  http://www.openstreetmap.org/way/237689576

 Parece o CEP

  http://www.openstreetmap.org/way/16973487
  http://www.openstreetmap.org/way/37396062
  http://www.openstreetmap.org/way/154255950

 Inicial de quem inseriu (pedro vida torta - PVT). Pode apagar (é
 considerado graffiti)
 Aproveita e manda mensagem para a pessoa parar com isso.

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br




-- 

... Edileuz, eu não tem nada a ver com Creuza,
   É mentira da Ivete, não é meu esse caniveete...
Halley, Luiz - Poeta, Cantor, Compsitor
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] São Paulo capital, tag reg

2014-03-14 Thread John Packer

ref é uma etiqueta genérica para Código de referência (corrijo o que
disse antes, não é número, é código).

Assim como para a etiqueta name, tem outras etiquetas
relacionadashttp://wiki.openstreetmap.org/wiki/Refpara usos
similares, como
loc_ref, old_ref, ref:* e outros.

A etiqueta ref pode ser utilizada para coisas como números de saída de uma
rodovia(junto com motorway_junction=*) e código de identificação de pontos
de ônibus.
Não é algo tão comum assim de usar.

Abs,
João


Em 14 de março de 2014 09:12, Marcelo Pereira pereirahol...@gmail.comescreveu:

 Taí uma tag que eu nunca entendi como preencher, REF

 Sempre que rodo o validador do JOSM, aparecem críticas relacionadas.

 E é tanta coisa colocada lá que fica dificil saber o que é mesmo para
 ficar.

 Marcelo


 2014-03-13 23:53 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:

 On Thu, Mar 13, 2014 at 11:47 PM, Erick de Oliveira Leal
 erickdeoliveiral...@gmail.com wrote:
  http://www.openstreetmap.org/way/38709823
  http://www.openstreetmap.org/way/237689576

 Parece o CEP

  http://www.openstreetmap.org/way/16973487
  http://www.openstreetmap.org/way/37396062
  http://www.openstreetmap.org/way/154255950

 Inicial de quem inseriu (pedro vida torta - PVT). Pode apagar (é
 considerado graffiti)
 Aproveita e manda mensagem para a pessoa parar com isso.

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br




 --

 ... Edileuz, eu não tem nada a ver com Creuza,
É mentira da Ivete, não é meu esse caniveete...
 Halley, Luiz - Poeta, Cantor, Compsitor

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] São Paulo capital, tag reg

2014-03-14 9:12 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com:
 Taí uma tag que eu nunca entendi como preencher, REF

De forma bem resumida, no Brasil ref vai ser comumente utilizada nas
saídas de rodovias (quando na placa tem Saída 430A você vai colocar
430A na ref) e nas rodovias (por exemplo, SP-300 ou BR-101).

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] São Paulo capital, tag reg

2014-03-14 Thread John Packer

Alterei a tradução de *Reference* no editor
iDhttps://www.transifex.com/projects/p/id-editor/translate/#pt_BR/presets/11487835?q=refpara
Código de referência.


Em 14 de março de 2014 09:23, Nelson A. de Oliveira nao...@gmail.comescreveu:

 2014-03-14 9:12 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com:
  Taí uma tag que eu nunca entendi como preencher, REF

 De forma bem resumida, no Brasil ref vai ser comumente utilizada nas
 saídas de rodovias (quando na placa tem Saída 430A você vai colocar
 430A na ref) e nas rodovias (por exemplo, SP-300 ou BR-101).

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho
helio_couti...@hotmail.com:
 Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns
 problemas:

Por acaso você está usando o poly daqui
http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro
para extrair o estado?
Caso sim, esse poly possui um buraco entre Rio e Niterói.

Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado
definido no OSM.

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

2014-03-14 Thread Lists

Eu uso http://gaemin.openstreetmap.nl/

Depois um tempo p gerar (muitos vezes instantanio) a mapa com qualquer 
poligonio voce quer ser disponível, geralmente gerando somente Brazil, mas 
dezembro passado girei Brazil com Portugal no mesmo mapa

Os arquivos e disponíveis em os mais usados formatos p garmin, eu teve nenhuma 
problema instalar atravez windows ou mac

Aun Johnsen

On Mar 14, 2014, at 10:03, Nelson A. de Oliveira nao...@gmail.com wrote:

 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho
 helio_couti...@hotmail.com:
 Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns
 problemas:
 
 Por acaso você está usando o poly daqui
 http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro
 para extrair o estado?
 Caso sim, esse poly possui um buraco entre Rio e Niterói.
 
 Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado
 definido no OSM.
 
 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Validador nacional

2014-03-14 Thread Marcelo Pereira

Osmanianos,


Lendo a frase Rivers and streams should not be tagged with layer -1 along
long sections of their length, eu entendo que a tag layer NÃO deve ser
usada em longas seções de rios e ( seja-lá-o-que-for ) streams.

Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em
uma camada diferente da entidade que ele cruza.


Mais uma frase :
A bridge is at layer 1 even if it is only several feet above sea level
while the peak of Mount Everest is at layer 0 even though it is 8848 meters
above sea level.

Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que
é o default e por isso não recomendado explicitar, e só se registra layer
onde houver claramente uma diferença de camada em um cruzamento.


Assim ...

Um exemplo prático e mais extremo: suponha que seja um rio com várias
pontes atravessando-o, como é o caso do arroio Dilúvio em Porto
Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o
cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra
constar: eu revisei uma por uma, e mapeei as que faltavam.)


Usando a minha interpretação da frase inicial, o uso neste exemplo dado
pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1
em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos
ou pontos, não em toda sua extensão.

E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes
e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da
terra ( layer=0), o elemento adicional são as pontes.



Adicionando uma questão a discussão, que diferença faz usar layer=1 na
ponte ou layer=-1 no rio ?

 - Pra renderização o que ficaria melhor ?
 - Pra roteamento, o que funcionaria melhor ?
 - Será que não seria bom padronizar ? ( no caso de comportamentos
diferentes para cada caso )

Marcelo P



Em 14 de março de 2014 06:58, Flavio Bello Fialho
bello.fla...@gmail.comescreveu:

 Fernando, acho que não entendeste. Leia a página
 http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz
 explicitamente:

 Do not use layer=-1 to hide warnings about crossing or overlapping ways.
 Either fix them or leave the easily visible warning so that others can fix
 them.

 When ways are passing on different levels apply layer=* only to the way
 which also has the bridge/tunnel attribute. Only ways with one of the
 tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator,
 covered=* should be tagged with the layer tag, similar for railways and
 waterways.

 Rivers and streams should not be tagged with layer -1 along long sections
 of their length

 Eles estão dizendo explicitamente para NÃO fazer isso que queres fazer. Se
 tens alguma dúvida, discuta na comunidade internacional. Esse é o meu
 último post sobre esse assunto.



 Em 14 de março de 2014 02:08, Fernando Trebien fernando.treb...@gmail.com
  escreveu:

 Mais além: na verdade, em alguns casos, chega a ser pior marcar as pontes
 com layer=1 porque isso altera a priorização da renderização no Mapnik. Por
 exemplo, highway=secondary_link com layer=1 é renderizado por cima de
 highway=primary (com ou sem layer=0). Isso é o oposto do normal e faz o
 desenho ficar feio.

 Mas o Mapnik não é o único parâmetro. No wiki diz que algumas ferramentas
 de QA (mas não todas) exigem que o rio tenha layer=-1 e a ponte tenha
 layer=1. Nada no restante do artigo sugere que isso é, de fato, necessário
 (pelo contrário). Pra mim, parece uma escolha arbitrária sem muita
 justificativa (ou seja, um dogma). Colocar layer=-1 no rio ou layer=1 na
 ponte estão ambos corretos, mas frequentemente uma das opções requer menos
 trabalho e resulta numa representação menos complexa.

 E se o próprio artigo diz que não é necessário colocar layer=0 nos casos
 em que seria esse o valor, me parece que o ideal é, quase sempre, marcar o
 rio com layer=-1, e nada mais.

 Claro, daí algumas pessoas poderiam pensar que não precisam marcar a
 ponte que passa por cima. Por isso concordo que o validador nacional aponte
 esses casos como aviso - que deve ser interpretado com bom senso (assim
 como os demais avisos do validador do JOSM) de acordo com a definição da
 tag, não necessariamente como erro.
 On Mar 14, 2014 1:34 AM, Fernando Trebien fernando.treb...@gmail.com
 wrote:

 Só complementando, o que layer=0 realmente significa é: desenhe este
 objeto depois dos que têm layer=-1, e antes dos que tÊm layer=1. Não
 significa nada além disso.

 2014-03-14 1:30 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
  Exemplo fácil (inclusive já tinha citado antes): 1 rio + 2 linhas de
  uma via separada. É mais fácil colocar layer=-1 no rio do que colocar
  2 tags layer=1, uma para cada linha da via.
 
  Um exemplo prático e mais extremo: suponha que seja um rio com várias
  pontes atravessando-o, como é o caso do arroio Dilúvio em Porto
  Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o
  cruzam, versus layer=-1 somente no arroio. 54

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

Obrigado!Vou tentar o novo Poly indicado para o Rj.Uma pergunta, e quanto ao 
mapa do Brasil, aparecem praticamente os mesmos problemas. Você teria como me 
indicar um outro arquivo Poly para o Brasil? 
Não querendo abusar, quando faço pesquisa de endereço no GPS com esses mapas, 
aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam incoerentes. 
O que pode ser isso?
Abs,

 From: li...@gimnechiske.org
 Date: Fri, 14 Mar 2014 10:06:45 -0300
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin 
 para download

 Eu uso http://gaemin.openstreetmap.nl/

 Depois um tempo p gerar (muitos vezes instantanio) a mapa com qualquer 
 poligonio voce quer ser disponível, geralmente gerando somente Brazil, mas 
 dezembro passado girei Brazil com Portugal no mesmo mapa

 Os arquivos e disponíveis em os mais usados formatos p garmin, eu teve 
 nenhuma problema instalar atravez windows ou mac

 Aun Johnsen

 On Mar 14, 2014, at 10:03, Nelson A. de Oliveira nao...@gmail.com wrote:

  2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho
  helio_couti...@hotmail.com:
  Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns
  problemas:

  Por acaso você está usando o poly daqui
  http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro
  para extrair o estado?
  Caso sim, esse poly possui um buraco entre Rio e Niterói.

  Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado
  definido no OSM.

  ___
  Talk-br mailing list
  Talk-br@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-br

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br
  ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Validador nacional

 - Pra renderização o que ficaria melhor ?

Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica
melhor nesse caso específico porque daí ele consegue conectar o
preenchimento e o contorno da via da ponte ao preenchimento e contorno
das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1.

Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho
próximo da ponte.

Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto.

Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto.

Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto.
Não é o que se esperaria tipicamente, mas está correto.

Todas essas formas levam exatamente ao mesmo rendering, exceto pela
questão da conexão entre a ponte e o resto da malha, que pode ser
vista como defeito do renderizador.

 - Pra roteamento, o que funcionaria melhor ?

Não faz absolutamente nenhuma diferença, essa é uma tag voltada
exclusivamente à renderização.

 - Será que não seria bom padronizar ? ( no caso de comportamentos
diferentes para cada caso )

Acho melhor entender a semântica da tag. Há muitas outras coisas em
que uma padronização seria muito mais importante, nesse caso uma
padronização rígida não faz diferença na prática.

2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com:
 Osmanianos,


 Lendo a frase Rivers and streams should not be tagged with layer -1 along
 long sections of their length, eu entendo que a tag layer NÃO deve ser
 usada em longas seções de rios e ( seja-lá-o-que-for ) streams.

 Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em
 uma camada diferente da entidade que ele cruza.


 Mais uma frase :
 A bridge is at layer 1 even if it is only several feet above sea level
 while the peak of Mount Everest is at layer 0 even though it is 8848 meters
 above sea level.

 Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que
 é o default e por isso não recomendado explicitar, e só se registra layer
 onde houver claramente uma diferença de camada em um cruzamento.


 Assim ...
 
 Um exemplo prático e mais extremo: suponha que seja um rio com várias
 pontes atravessando-o, como é o caso do arroio Dilúvio em Porto
 Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o
 cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra
 constar: eu revisei uma por uma, e mapeei as que faltavam.)
 

 Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo
 Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em
 todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou
 pontos, não em toda sua extensão.

 E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes
 e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da
 terra ( layer=0), o elemento adicional são as pontes.



 Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte
 ou layer=-1 no rio ?

  - Pra renderização o que ficaria melhor ?
  - Pra roteamento, o que funcionaria melhor ?
  - Será que não seria bom padronizar ? ( no caso de comportamentos
 diferentes para cada caso )

 Marcelo P



 Em 14 de março de 2014 06:58, Flavio Bello Fialho bello.fla...@gmail.com
 escreveu:

 Fernando, acho que não entendeste. Leia a página
 http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz
 explicitamente:

 Do not use layer=-1 to hide warnings about crossing or overlapping ways.
 Either fix them or leave the easily visible warning so that others can fix
 them.

 When ways are passing on different levels apply layer=* only to the way
 which also has the bridge/tunnel attribute. Only ways with one of the
 tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator,
 covered=* should be tagged with the layer tag, similar for railways and
 waterways.

 Rivers and streams should not be tagged with layer -1 along long sections
 of their length

 Eles estão dizendo explicitamente para NÃO fazer isso que queres fazer. Se
 tens alguma dúvida, discuta na comunidade internacional. Esse é o meu último
 post sobre esse assunto.



 Em 14 de março de 2014 02:08, Fernando Trebien
 fernando.treb...@gmail.com escreveu:

 Mais além: na verdade, em alguns casos, chega a ser pior marcar as pontes
 com layer=1 porque isso altera a priorização da renderização no Mapnik. Por
 exemplo, highway=secondary_link com layer=1 é renderizado por cima de
 highway=primary (com ou sem layer=0). Isso é o oposto do normal e faz o
 desenho ficar feio.

 Mas o Mapnik não é o único parâmetro. No wiki diz que algumas ferramentas
 de QA (mas não todas) exigem que o rio tenha layer=-1 e a ponte tenha
 layer=1. Nada no restante do artigo sugere que isso é, de fato, necessário
 (pelo contrário). Pra mim, parece uma escolha arbitrária sem muita
 justificativa (ou seja, um dogma). Colocar layer=-1 no rio ou layer=1 na
 ponte estão ambos corretos, mas frequentemente

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

2014-03-14 10:39 GMT-03:00 Hélio Ricardo Pinheiro Coutinho
helio_couti...@hotmail.com:
 Uma pergunta, e quanto ao mapa do Brasil, aparecem praticamente os mesmos
 problemas. Você teria como me indicar um outro arquivo Poly para o Brasil?

Tem esse aqui: 
https://raw.github.com/osmandapp/OsmAnd-misc/master/osm-planet/geo-polygons/south-america/brazil.poly

 Não querendo abusar, quando faço pesquisa de endereço no GPS com esses
 mapas, aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam
 incoerentes. O que pode ser isso?

Essa parte eu já não sei te dizer (eu não tenho um Garmin para testar).

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

Em 14 de março de 2014 08:13, Hélio Ricardo Pinheiro Coutinho 
helio_couti...@hotmail.com escreveu:

 PessoALL,

  Sou do Rio de Janeiro e estou dando manutenção no OSM desde novembro
 de 2013 (estou aprendendo bastante!) e vim pedir ajuda, principalmente aos
 colaboradores do Rio de Janeiro que conhecem bem os trechos que irei
 falar...
  Fiquei bastante contente ao conseguir minha primeira compilação,
 depois de algumas tentativas e erros, finalmente tenho um script que roda
 liso. Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns
 problemas:

 *Mapa RJ:*

   A ponte Rio/Niterói só vai até a ilha de Mocanguê sentido
 Niterói/Rio e aparece uma outra estrada ao lado que parece ser ela.


Parece ter a ver com o arquivo .poly usado, conforme falado pelo Nelson.
Coisa de simples solução.



  O contorno da orla vindo pela Av. do Contorno está dentro d'água e vai
 assim por toda orla de Niterói, as ruas da Ilha da Conceição(Niterói) estão
 sobre a Baia de Guanabara.


Pode ser o arquivo de oceano default que vem no mkgmap.  Devemos usar um
outro e passar para o compilador.


   Tracei uma rota de São Gonçalo (onde moro) até João Pessoa e para
 minha surpresa, o GPS começa a rota por uma estrada(possivelmente a BR-101)
 só que pelo meio de São Gonçalo e não pela orla (onde ela realmente passa),
 esta estrada virtual no visual fica por baixo do mapa, só aparece em
 alguns trechos.


Isso precisa ser melhor explicado.  É problema que veio do mapa-base?  Está
só no GPS?



 *Mapa Brasil:*

   A ponte Rio/Niterói aparentemente está correta. Porém a estrada
 virtual aparece no meio de São Gonçalo e os problemas visuais da orla,
 ruas dentro d'água continuam.


Que rua virtual é essa?  Tem como postar uma captura de tela?  Está com
outros mapas habilitados no GPS?




 Os mapas disponíveis no projeto COCAR estão com os mesmos problemas, e o
 do site oficial do OSM tem um problemas parecido no bairro de Alcantara/São
 Gonçalo, algumas ruas não aprecem no mapa compilado (no GPS).


Ruas faltantes no mapa podem ser acrescentadas editando o mapa.  Não
estamos mais no Tracksource. ;-P



 Obrigado pela atenção,

 Hélio Coutinho.


 --
 Date: Tue, 11 Mar 2014 11:21:56 -0300
 From: paulo.r.m.carva...@gmail.com
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas
 Garmin para download

 335 é o código IBGE para SP.  Na verdade 35. O 3 a mais seria região
 sudeste.  Isso é para nos certificar de que não haja colisão de IDs caso o
 usuário instale mais de um mapa.  O do RJ é 333.  Mas esse código poderia
 ser qualquer um que quiséssemos inventar, desde que seja único.

 Colocarei um link lá no Cocar.  Aliás tenho que fazer uma página com a
 relação de mapas, (que tende a crescer) e citar a cortesia.  Os links no
 menu não vão dar certo.

 [ ]s e obrigado.

 Paulo


 2014-03-11 9:43 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:

 --mapid não existe
 Para family-id e product-id, tem algo em específico para serem 335?

 Tirando isso, o de SP está aqui:
 http://naoliv.iq.unesp.br/mapas/gmapsupp.img

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br



 ___ Talk-br mailing list
 Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

Nelson,
   Obrigado mais uma vez!   Este Poly que você me indicou só tem 5KB o que usei 
tem 2133KB, é isso mesmo?
Abs,

 Date: Fri, 14 Mar 2014 10:53:03 -0300
 From: nao...@gmail.com
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br]Kit para compilação Garmin em Windows e mapas 
 Garmin para download

 2014-03-14 10:39 GMT-03:00 Hélio Ricardo Pinheiro Coutinho
 helio_couti...@hotmail.com:
  Uma pergunta, e quanto ao mapa do Brasil, aparecem praticamente os mesmos
  problemas. Você teria como me indicar um outro arquivo Poly para o Brasil?

 Tem esse aqui: 
 https://raw.github.com/osmandapp/OsmAnd-misc/master/osm-planet/geo-polygons/south-america/brazil.poly

  Não querendo abusar, quando faço pesquisa de endereço no GPS com esses
  mapas, aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam
  incoerentes. O que pode ser isso?

 Essa parte eu já não sei te dizer (eu não tenho um Garmin para testar).

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br
  ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Validador nacional

Do not use layer=-1 to *hide warnings* about crossing or overlapping ways.
Either *fix them* or leave the easily visible warning so that others can
fix them.

Quem disse está sendo feito assim para esconder alertas? Eu tratei cada
um dos alertas originais, e por fim coloquei layer=-1 no rio. Está de
acordo com a instrução.

When ways are passing on different levels apply layer=* only to the way
which also has the bridge/tunnel attribute. Only ways with one of the
tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator,
covered=* should be tagged with the layer tag, similar for railways and
waterways. (...) Rivers and streams should not be tagged with layer -1
along long sections of their length

Não há uma explicação de por que isso é ruim/errado. Tem algumas pessoas na
página Discussion que pensam diferente. Vou copiar alguns trechos:

- For complex motorway junctions, bridges may themselves be bridged. In
other circumstances, tunnels may themselves be tunneled under. So bridges
can be layer +1, +2, etc. A bridge may go over something which has layer
-1, so the bridge would be *layer 0* etc. etc. Richard B 12:40, 3 September
2008 (UTC)

- It's hardly a big issue to have a few objects tagged in this way. *Just
remember also how the renderer works.* Objects in layer -5 are drawn first.
Then objects in layer -4 are drawn on top. Then objects in layer -3 etc.
Finally objects in layer +5 are drawn last. That has got to be simpler than
requiring the renderers to have filters based on defaults for some objects,
and still requiring layer tags for more complicated examples. Remember that
bridges might be tagged bridge=yes, bridge=true, or even ones that specify
what type of bridge it is, bridge=swing etc.For what it's worth, data for
the UK shows (on ways tagged bridge=yes and bridge=true);

2 bridges with layer=-2 (0.0%)
59 bridges with layer=-1 (0.4%)
22 bridges with layer=0 (0.2%)
12813 bridges with layer=1 (91.7%)
896 bridges with layer=2 (6.4%)
126 bridges with layer=3 (0.9%)
43 bridges with layer=4 (0.3%)
9 bridges with layer=5 (0.1%)

So nearly 10% of all bridges are tagged in a different layer than 1.
Tagging something with a layer tag can only be redundant if one implies the
other. It clearly does not. Looking at the stats for tunnels in European
tagging suggests there are *tunnels tagged between layer=3 and layer=-6*.

- *Only the relative order is important*, *not the actual values used*, so
there is nothing wrong with non-consecutive layers (e.g. object with
layer=4 directly over object with layer=-2), and bridges having negative
and tunnels having positive layers.

- I use the layer key on all *bridges and tunnels. Usually this means
layers 1 and -1*, respectively, but *it gets more complicated in urban
environments*. *Rivers through cities typically get layer=-1 because they
consistently pass under the street level*. *Bridges over such rivers are
often layer=0*, especially if they have intersecting streets immediately at
one or both ends of the bridge. The same is true when a motorway is below
street level. And when a motorway or rail line is consistently above street
level, the whole thing gets layer=1 and not just the parts that are
actually on bridges. I also try to make both parts of a divided highway be
on the same layer (assuming they're physically at the same level) and make
the transition from one layer to another at about the same point. Generally
speaking, for any two features that cross or are very close to each other,
I try to represent the relative physical height difference. Not only is
this a good semantic representation of the physical world, but doing it
this way (as opposed to bare-minimum use of the layer key) tends to produce
slightly better map renders. That's a win-win. Vid the Kid 23:07, 13 April
2009 (UTC)

- This seems self-contradictory: *If layer has no meanings for absolute
heights*, then *it doesn't matter whether to put the layer on the stream or
the bridge*, and whether to choose layer=-1 for the bridge and layer=-4 for
the stream, or 1 and 0 resp.

Eu acho que o problema que você quer evitar vem na resposta a essa última
observação:

- Of course layer is relative, and you could tag the waterway as layer=-5
and the bridge as layer=-4, but *usually the waterway will not be split
into a small piece* under the bridge and everything else, so the
layer=-5 applies to the whole waterway - and *that is bad*. SvenR 21:07, 23
January 2009 (UTC)

Não faz sentido considerar errado, já que não afeta nenhuma aplicação - a
não ser validadores, que bem poderiam estar validando uma regra um pouco
mais inteligente como esta: alertar quando 2 linhas com o mesmo valor em
layer (incluindo layer=0 implícito) se cruzam:
- sem ponto compartilhado: quaisquer tipos de vias
- com ponto compartilhado: vias de tipos diferentes (highway+waterway)

Dito isto, como é feito na prática? O rio Tâmisa, em Londres, o rio Sena,
em Paris, e o rio Danúbio, em Viena, estão da forma que você

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

2014-03-14 11:07 GMT-03:00 Hélio Ricardo Pinheiro Coutinho
helio_couti...@hotmail.com:
Este Poly que você me indicou só tem 5KB o que usei tem 2133KB, é isso
 mesmo?

Sim, está certo :-)
É uma versão mais simplificada, com número menor de nós.

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

Boa, Nelson, vou incluir esse poly no kit.  A propósito, você teria por aí
os polys dos outros estados?

[]s

PC


Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.comescreveu:

 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho
 helio_couti...@hotmail.com:
  Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns
  problemas:

 Por acaso você está usando o poly daqui
 http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro
 para extrair o estado?
 Caso sim, esse poly possui um buraco entre Rio e Niterói.

 Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado
 definido no OSM.

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Validador nacional

Qual a origem desse dogma, na minha opinião: ao importar a hidrografia
de uma certa região, alguns importadores acharam mais conveniente
colocar layer=-1 em todos os rios pra se livrar dos alertas do JOSM do
que deixar os alertas e, quem sabe, adicionar as pontes corretamente.

Bem, tem 1 coisa errada com essa idéia: o JOSM deveria alertar sobre a
falta de uma ponte nesses casos porque layer=-1 não significa
subterrâneo.

É bem possível também que o próprio importador estivesse entendendo
alerta no JOSM como erro, mas são coisas diferentes.

Tem outra coisa: o importador deveria ter previsto esse efeito
colateral antes de importar. Por isso que não se pode sair importando
as coisas de qualquer jeito sem conversar com a comunidade antes pra
ver se vai funcionar.

Caso isso tenha acontecido (como se pergunta no fim da página de
discussão), a melhor forma de resolver a situação é: baixar o mapa,
mudar a tag layer dos rios para layer=0 (ou simplesmente excluí-la),
rodar o validador, e mapear as pontes onde o validador tiver dado um
aviso. Tanto faz o valor que vai em layer, desde que a layer do rio
seja inferior à layer da ponte (ou, equivalentemente, que a layer da
ponte seja superior à do rio). Ou seja, depois de mapeadas as pontes,
daria pra colocar layer=-1 (ou -2, ou -5) de novo nos rios (inclusive
durante a mesma edição). Também daria colocar layer nas pontes. Enfim,
a escolha é livre.

2014-03-14 10:52 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
  - Pra renderização o que ficaria melhor ?

 Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica
 melhor nesse caso específico porque daí ele consegue conectar o
 preenchimento e o contorno da via da ponte ao preenchimento e contorno
 das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1.

 Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho
 próximo da ponte.

 Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto.

 Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto.

 Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto.
 Não é o que se esperaria tipicamente, mas está correto.

 Todas essas formas levam exatamente ao mesmo rendering, exceto pela
 questão da conexão entre a ponte e o resto da malha, que pode ser
 vista como defeito do renderizador.

  - Pra roteamento, o que funcionaria melhor ?

 Não faz absolutamente nenhuma diferença, essa é uma tag voltada
 exclusivamente à renderização.

  - Será que não seria bom padronizar ? ( no caso de comportamentos
 diferentes para cada caso )

 Acho melhor entender a semântica da tag. Há muitas outras coisas em
 que uma padronização seria muito mais importante, nesse caso uma
 padronização rígida não faz diferença na prática.

 2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com:
 Osmanianos,


 Lendo a frase Rivers and streams should not be tagged with layer -1 along
 long sections of their length, eu entendo que a tag layer NÃO deve ser
 usada em longas seções de rios e ( seja-lá-o-que-for ) streams.

 Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em
 uma camada diferente da entidade que ele cruza.


 Mais uma frase :
 A bridge is at layer 1 even if it is only several feet above sea level
 while the peak of Mount Everest is at layer 0 even though it is 8848 meters
 above sea level.

 Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que
 é o default e por isso não recomendado explicitar, e só se registra layer
 onde houver claramente uma diferença de camada em um cruzamento.


 Assim ...
 
 Um exemplo prático e mais extremo: suponha que seja um rio com várias
 pontes atravessando-o, como é o caso do arroio Dilúvio em Porto
 Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o
 cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra
 constar: eu revisei uma por uma, e mapeei as que faltavam.)
 

 Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo
 Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em
 todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou
 pontos, não em toda sua extensão.

 E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes
 e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da
 terra ( layer=0), o elemento adicional são as pontes.



 Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte
 ou layer=-1 no rio ?

  - Pra renderização o que ficaria melhor ?
  - Pra roteamento, o que funcionaria melhor ?
  - Será que não seria bom padronizar ? ( no caso de comportamentos
 diferentes para cada caso )

 Marcelo P



 Em 14 de março de 2014 06:58, Flavio Bello Fialho bello.fla...@gmail.com
 escreveu:

 Fernando, acho que não entendeste. Leia a página
 http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz
 explicitamente:

 Do not use layer=-1 to hide warnings about

Re: [Talk-br] Why Imports in OpenStreetMap Are Controversial

Bom, manter um mapa atualizado é um desafio.  Não vejo porque esse seria um
problema exclusivo da parte que é importada.  Meu primeiro tracklog
(enviado ao Tracksource) foi de uma rampa de asa-delta que visitei em
Congonhal-MG em 2004.  Nem sei se ainda existe.


2014-03-14 8:56 GMT-03:00 Wille wi...@wille.blog.br:

 Há um novo texto no blog do Serge sobre a dificuldade de manutenção de
 dados importados no OSM: http://blog.emacsen.net/blog/
 2014/03/13/the-maintenance-of-imported-data-in-openstreetmap/

 On 04-02-2014 19:59, Wille wrote:

 Compartilho um texto muito bom sobre a questão das importações no OSM:
 http://blog.emacsen.net/blog/2014/01/25/why-imports-in-openstreetmap-are-
 controversial/

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br



 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

Paulo Carvalho,
   - O mapa base pego daqui (como está indicado na BAT do projeto COCAR):
http://download.geofabrik.de/south-america/brazil-latest.osm.pbf
   - Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite... 
   - Procuro sempre habilitar um mapa por vez...
   - Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas e 
bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de nos 
entendermos.
Obrigado,
Hélio Coutinho.
Date: Fri, 14 Mar 2014 11:09:22 -0300
From: paulo.r.m.carva...@gmail.com
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br]  Kit para compilação Garmin em Windows e mapas Garmin 
para download

Boa, Nelson, vou incluir esse poly no kit.  A propósito, você teria por aí os 
polys dos outros estados?

[]s

PC



Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.com escreveu:

2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho

helio_couti...@hotmail.com:

 Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns

 problemas:



Por acaso você está usando o poly daqui

http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro

para extrair o estado?

Caso sim, esse poly possui um buraco entre Rio e Niterói.



Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado

definido no OSM.



___

Talk-br mailing list

Talk-br@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-br




___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
  ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

Hélio,

   Se você apontar um exemplo (dando nome da Rua ou apontando no OSM) eu
mesmo faço a verificação no meu GPS contra o mapa-base do OSM.

[ ]s

Paulo


Em 14 de março de 2014 11:17, Hélio Ricardo Pinheiro Coutinho 
helio_couti...@hotmail.com escreveu:

 Paulo Carvalho,

- O mapa base pego daqui (como está indicado na BAT do projeto COCAR):

 http://download.geofabrik.de/south-america/brazil-latest.osm.pbf

- Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite...

- Procuro sempre habilitar um mapa por vez...

- Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas
 e bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de
 nos entendermos.

 Obrigado,

 Hélio Coutinho.

 --
 Date: Fri, 14 Mar 2014 11:09:22 -0300
 From: paulo.r.m.carva...@gmail.com
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas
 Garmin para download

 Boa, Nelson, vou incluir esse poly no kit.  A propósito, você teria por aí
 os polys dos outros estados?

 []s

 PC


 Em 14 de março de 2014 10:03, Nelson A. de Oliveira 
 nao...@gmail.comescreveu:

 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho
 helio_couti...@hotmail.com:
  Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns
  problemas:

 Por acaso você está usando o poly daqui
 http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro
 para extrair o estado?
 Caso sim, esse poly possui um buraco entre Rio e Niterói.

 Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado
 definido no OSM.

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br



 ___ Talk-br mailing list
 Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

2014-03-14 11:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com:
 Boa, Nelson, vou incluir esse poly no kit.  A propósito, você teria por aí
 os polys dos outros estados?

Posso gerar. Hoje e fim de semana está meio corrido, mas no máximo até
segunda eu gero de todos.

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

Paulo, segue,
https://www.openstreetmap.org/way/204618440#map=19/-22.82102/-42.99988

Rua Almirante Nestor Pinto Alves (ao lado do Supermercado Extra) aparece no ID 
e não aparece no mapa OSM no GPS, entre outras próximas.
Abs,
Hélio.
Date: Fri, 14 Mar 2014 11:20:38 -0300
From: paulo.r.m.carva...@gmail.com
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br]  Kit para compilação Garmin em Windows e mapas Garmin 
para download

Hélio,

   Se você apontar um exemplo (dando nome da Rua ou apontando no OSM) eu mesmo 
faço a verificação no meu GPS contra o mapa-base do OSM.

[ ]s

Paulo

Em 14 de março de 2014 11:17, Hélio Ricardo Pinheiro Coutinho 
helio_couti...@hotmail.com escreveu:

Paulo Carvalho,
   - O mapa base pego daqui (como está indicado na BAT do projeto COCAR):
http://download.geofabrik.de/south-america/brazil-latest.osm.pbf

   - Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite... 
   - Procuro sempre habilitar um mapa por vez...
   - Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas e 
bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de nos 
entendermos.

Obrigado,
Hélio Coutinho.
Date: Fri, 14 Mar 2014 11:09:22 -0300
From: paulo.r.m.carva...@gmail.com

To: talk-br@openstreetmap.org
Subject: Re: [Talk-br]  Kit para compilação Garmin em Windows e mapas Garmin 
para download

Boa, Nelson, vou incluir esse poly no kit.  A propósito, você teria por aí os 
polys dos outros estados?

[]s

PC

Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.com escreveu:

2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho

helio_couti...@hotmail.com:

 Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns

 problemas:

Por acaso você está usando o poly daqui

http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro

para extrair o estado?

Caso sim, esse poly possui um buraco entre Rio e Niterói.

Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado

definido no OSM.

___

Talk-br mailing list

Talk-br@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

___

Talk-br mailing list

Talk-br@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
  ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download

Nélson, não tenha pressa.  Pensei que talvez você os já tivesse prontos.
Mas se dispondo a gerá-los, só temos a agradecer.

[]s

Paulo


Em 14 de março de 2014 11:20, Nelson A. de Oliveira nao...@gmail.comescreveu:

 2014-03-14 11:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com:
  Boa, Nelson, vou incluir esse poly no kit.  A propósito, você teria por
 aí
  os polys dos outros estados?

 Posso gerar. Hoje e fim de semana está meio corrido, mas no máximo até
 segunda eu gero de todos.

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Validador nacional

Pra quem quiser acompanhar:
https://lists.openstreetmap.org/pipermail/tagging/2014-March/016865.html

2014-03-14 11:10 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
 Qual a origem desse dogma, na minha opinião: ao importar a hidrografia
 de uma certa região, alguns importadores acharam mais conveniente
 colocar layer=-1 em todos os rios pra se livrar dos alertas do JOSM do
 que deixar os alertas e, quem sabe, adicionar as pontes corretamente.

 Bem, tem 1 coisa errada com essa idéia: o JOSM deveria alertar sobre a
 falta de uma ponte nesses casos porque layer=-1 não significa
 subterrâneo.

 É bem possível também que o próprio importador estivesse entendendo
 alerta no JOSM como erro, mas são coisas diferentes.

 Tem outra coisa: o importador deveria ter previsto esse efeito
 colateral antes de importar. Por isso que não se pode sair importando
 as coisas de qualquer jeito sem conversar com a comunidade antes pra
 ver se vai funcionar.

 Caso isso tenha acontecido (como se pergunta no fim da página de
 discussão), a melhor forma de resolver a situação é: baixar o mapa,
 mudar a tag layer dos rios para layer=0 (ou simplesmente excluí-la),
 rodar o validador, e mapear as pontes onde o validador tiver dado um
 aviso. Tanto faz o valor que vai em layer, desde que a layer do rio
 seja inferior à layer da ponte (ou, equivalentemente, que a layer da
 ponte seja superior à do rio). Ou seja, depois de mapeadas as pontes,
 daria pra colocar layer=-1 (ou -2, ou -5) de novo nos rios (inclusive
 durante a mesma edição). Também daria colocar layer nas pontes. Enfim,
 a escolha é livre.

 2014-03-14 10:52 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
  - Pra renderização o que ficaria melhor ?

 Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica
 melhor nesse caso específico porque daí ele consegue conectar o
 preenchimento e o contorno da via da ponte ao preenchimento e contorno
 das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1.

 Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho
 próximo da ponte.

 Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto.

 Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto.

 Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto.
 Não é o que se esperaria tipicamente, mas está correto.

 Todas essas formas levam exatamente ao mesmo rendering, exceto pela
 questão da conexão entre a ponte e o resto da malha, que pode ser
 vista como defeito do renderizador.

  - Pra roteamento, o que funcionaria melhor ?

 Não faz absolutamente nenhuma diferença, essa é uma tag voltada
 exclusivamente à renderização.

  - Será que não seria bom padronizar ? ( no caso de comportamentos
 diferentes para cada caso )

 Acho melhor entender a semântica da tag. Há muitas outras coisas em
 que uma padronização seria muito mais importante, nesse caso uma
 padronização rígida não faz diferença na prática.

 2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com:
 Osmanianos,


 Lendo a frase Rivers and streams should not be tagged with layer -1 along
 long sections of their length, eu entendo que a tag layer NÃO deve ser
 usada em longas seções de rios e ( seja-lá-o-que-for ) streams.

 Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em
 uma camada diferente da entidade que ele cruza.


 Mais uma frase :
 A bridge is at layer 1 even if it is only several feet above sea level
 while the peak of Mount Everest is at layer 0 even though it is 8848 meters
 above sea level.

 Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que
 é o default e por isso não recomendado explicitar, e só se registra layer
 onde houver claramente uma diferença de camada em um cruzamento.


 Assim ...
 
 Um exemplo prático e mais extremo: suponha que seja um rio com várias
 pontes atravessando-o, como é o caso do arroio Dilúvio em Porto
 Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o
 cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra
 constar: eu revisei uma por uma, e mapeei as que faltavam.)
 

 Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo
 Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em
 todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou
 pontos, não em toda sua extensão.

 E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes
 e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da
 terra ( layer=0), o elemento adicional são as pontes.



 Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte
 ou layer=-1 no rio ?

  - Pra renderização o que ficaria melhor ?
  - Pra roteamento, o que funcionaria melhor ?
  - Será que não seria bom padronizar ? ( no caso de comportamentos
 diferentes para cada caso )

 Marcelo P



 Em 14 de março de 2014 06:58, Flavio Bello Fialho

[Talk-br] Porto Velho - Rios sobrepostos

2014-03-14 Thread Erick de Oliveira Leal

Pessoal, qual devo deixar desses dois rios sobrepostos?

http://www.openstreetmap.org/browse/way/151882080
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Porto Velho - Rios sobrepostos

2014-03-14 14:48 GMT-03:00 Erick de Oliveira Leal
erickdeoliveiral...@gmail.com:
 Pessoal, qual devo deixar desses dois rios sobrepostos?

 http://www.openstreetmap.org/browse/way/151882080

Não é sobreposto. Um é o rio em si e o outro a área do rio.
Está certo (só teria que ajustar a área dele)

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Porto Velho - Rios sobrepostos

2014-03-14 Thread Ronaldo Maia

Pelo que eu sei, em rios vc pode desenhar uma área para marcar o
espaço que ele ocupa, e também pode desenhar uma linha para marcar o
seu curso (principalmente para ser usado quando for feito um
planejamento de navegação), Talvez o que precise se feito ali é
somente o ajuste do curso do rio.

2014-03-14 14:48 GMT-03:00 Erick de Oliveira Leal
erickdeoliveiral...@gmail.com:
 Pessoal, qual devo deixar desses dois rios sobrepostos?

 http://www.openstreetmap.org/browse/way/151882080

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br




-- 
Ronaldo Maia

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas em Natal

Troquei as respostas :-)

Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa.
Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro
lado da avenida e os trechos dela), deixa a avenida de forma correta
(mão dupla).

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas em Natal

2014-03-14 Thread Bráulio

Do jeito que está está correto. Está assim por causa das obras da copa.


2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal 
erickdeoliveiral...@gmail.com:

 Okay. Vou ver quem esta ativo lá e perguntar.
 Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com escreveu:

 Troquei as respostas :-)

 Pra http://www.openstreetmap.org/way/42433318 você pergunta para a
 pessoa.
 Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro
 lado da avenida e os trechos dela), deixa a avenida de forma correta
 (mão dupla).

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas em Natal

2014-03-14 Thread Erick de Oliveira Leal

Braulio. Então nos dois casos é pra deixar?
Em 14/03/2014 16:52, Bráulio brauliobeze...@gmail.com escreveu:

 Do jeito que está está correto. Está assim por causa das obras da copa.


 2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal 
 erickdeoliveiral...@gmail.com:

 Okay. Vou ver quem esta ativo lá e perguntar.
 Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com escreveu:

 Troquei as respostas :-)

 Pra http://www.openstreetmap.org/way/42433318 você pergunta para a
 pessoa.
 Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro
 lado da avenida e os trechos dela), deixa a avenida de forma correta
 (mão dupla).

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br



 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas em Natal

2014-03-14 16:52 GMT-03:00 Bráulio brauliobeze...@gmail.com:
 Do jeito que está está correto. Está assim por causa das obras da copa.

Aqui onde a avenida Aminta Barros, na parte de cima, muda de direção
na Rua Professor Antônio Campos (ficando com os dois sentidos dela
para uma única direção), está certo? (até o lado direito da Campos é
duas mãos; lado esquerdo 2 caminhos pro mesmo sentido)
http://osm.org/go/PT3vaLN7v

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas em Natal

2014-03-14 Thread Bráulio

Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta)
estão com alguns trechos em mão única, mesmo onde há canteiro central.

Há mais alterações além dessas, mas não estou conseguindo acompanhar :(.
Mas pelo menos essa mais importantes e duradouras eu coloquei no mapa.


2014-03-14 16:53 GMT-03:00 Erick de Oliveira Leal 
erickdeoliveiral...@gmail.com:

 Braulio. Então nos dois casos é pra deixar?
 Em 14/03/2014 16:52, Bráulio brauliobeze...@gmail.com escreveu:

 Do jeito que está está correto. Está assim por causa das obras da copa.


 2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal 
 erickdeoliveiral...@gmail.com:

 Okay. Vou ver quem esta ativo lá e perguntar.
 Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com
 escreveu:

 Troquei as respostas :-)

 Pra http://www.openstreetmap.org/way/42433318 você pergunta para a
 pessoa.
 Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro
 lado da avenida e os trechos dela), deixa a avenida de forma correta
 (mão dupla).

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br



 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas em Natal

2014-03-14 16:57 GMT-03:00 Bráulio brauliobeze...@gmail.com:
 Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta)
 estão com alguns trechos em mão única, mesmo onde há canteiro central.

Faltou um note explicando isso então ;-)

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas em Natal

2014-03-14 Thread Erick de Oliveira Leal

Braulio. Eu não vou corrigir, vou deixar pra você que tem mais conhecimento
do caso.
Em 14/03/2014 17:03, Nelson A. de Oliveira nao...@gmail.com escreveu:

 2014-03-14 16:57 GMT-03:00 Bráulio brauliobeze...@gmail.com:
  Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta)
  estão com alguns trechos em mão única, mesmo onde há canteiro central.

 Faltou um note explicando isso então ;-)

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br

___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread NopMap

Hi!

Um wieder auf die Originalmail zurückzukommen:
- der Verfasser gibt keine Auskunft über seine Identität oder Legitimation
dort überhaupt etwas zu fordern.
- er macht eine ominöse Andeutung von erheblichen Problemen, nennt aber
die angeblichen Probleme nicht
- er spricht von Straftaten, aber wenn man genau liest bringt selbst er
diese Straftaten nicht mit OSM in Zusammenhang, er sagt nur dort sei
irgendwann irgendwas passiert.

Ich sehe keinerlei Grund hier irgendetwas zu löschen. Es handelt sich um
Fakten über weithin sichtbare Objekte und ein Betreten ist für das Erfassen
der Position nicht erforderlich, dadurch werden keine Rechte berührt.

Ich bin mir ziemlich sicher, daß es sich nur um einen Privatmann (vermutlich
Jagdpächter) handelt und nicht um z.B. einen Fortsbeamten mit offizieller
Befugnis. Eine offizielle Stelle hätte sich mit vollem Namen gemeldet und
auf ihre Legitimation und Zuständigkeit hingewiesen.

Ich würde dem Verfasser mitteilen, daß ohne konkrete Informationen nichts
aus OSM gelöscht wird und ihn auffordern, die Probleme detailliert
auszuführen, damit man sich selbst ein Bild von deren Ausmaß machen kann.
Vor allem muß er den Zusammenhang zu OSM zu belegen.

Ferner wäre es eine Überlegung wert, die Flucht nach vorn antreten und sich
beim zuständigen Forstamt nach den angeblichen Problemen und deren Sicht auf
die Dinge zu erkundigen. Am besten durch einen ortskundigen Mapper. Das
sollte eine objektivere Meinung liefern. Ehrlich gesagt würde ich erwarten,
daß das Forstamt nichts von irgendwelchen Problemen weiß oder zumindest
keinen Sinn darin sieht, weithin sichtbare Objekte durch Entfernen auf der
Karte geheim zu halten. Und dann hätte der Verfasser nichts mehr in der
Hand und einen EditWar oder Streitigkeiten fortzusetzen.

bye, Nop

--
View this message in context:
http://gis.19327.n5.nabble.com/Hochsitze-Bitte-um-Entfernung-von-Daten-tp5799540p5799652.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread tumsi


+1

Sachliche Argumentation und sehr gute Vorschläge wie ich finde!


 Original-Nachricht 
Betreff: Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Datum: Fri Mar 14 2014 07:52:10 GMT+0100
Von: NopMap ekkeh...@gmx.de
An: talk-de@openstreetmap.org


Hi!

Um wieder auf die Originalmail zurückzukommen:
- der Verfasser gibt keine Auskunft über seine Identität oder Legitimation
dort überhaupt etwas zu fordern.
- er macht eine ominöse Andeutung von erheblichen Problemen, nennt aber
die angeblichen Probleme nicht
- er spricht von Straftaten, aber wenn man genau liest bringt selbst er
diese Straftaten nicht mit OSM in Zusammenhang, er sagt nur dort sei
irgendwann irgendwas passiert.

Ich sehe keinerlei Grund hier irgendetwas zu löschen. Es handelt sich um
Fakten über weithin sichtbare Objekte und ein Betreten ist für das Erfassen
der Position nicht erforderlich, dadurch werden keine Rechte berührt.

Ich bin mir ziemlich sicher, daß es sich nur um einen Privatmann (vermutlich
Jagdpächter) handelt und nicht um z.B. einen Fortsbeamten mit offizieller
Befugnis. Eine offizielle Stelle hätte sich mit vollem Namen gemeldet und
auf ihre Legitimation und Zuständigkeit hingewiesen.

Ich würde dem Verfasser mitteilen, daß ohne konkrete Informationen nichts
aus OSM gelöscht wird und ihn auffordern, die Probleme detailliert
auszuführen, damit man sich selbst ein Bild von deren Ausmaß machen kann.
Vor allem muß er den Zusammenhang zu OSM zu belegen.

Ferner wäre es eine Überlegung wert, die Flucht nach vorn antreten und sich
beim zuständigen Forstamt nach den angeblichen Problemen und deren Sicht auf
die Dinge zu erkundigen. Am besten durch einen ortskundigen Mapper. Das
sollte eine objektivere Meinung liefern. Ehrlich gesagt würde ich erwarten,
daß das Forstamt nichts von irgendwelchen Problemen weiß oder zumindest
keinen Sinn darin sieht, weithin sichtbare Objekte durch Entfernen auf der
Karte geheim zu halten. Und dann hätte der Verfasser nichts mehr in der
Hand und einen EditWar oder Streitigkeiten fortzusetzen.

bye, Nop



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread tumsi




 Original-Nachricht 
Betreff: Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Datum: Thu Mar 13 2014 22:15:42 GMT+0100
Von: Christian H. Bruhn br...@arcor.de
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org


Hochsitze sind allgemein gut sichtbar, wenn man sich in Wald und Flur
bewegt. Die kann man auch ohne OSM finden, und falls doch OSM genutzt
wurde, sehe ich darin auch keine Mitschuld. Man kann die Wahrheit
nicht verstecken. Nutzen sie nicht OSM, dann vielleicht
Google-Satelitenbilder oder sie suchen selbst.


In einigen Waldgebieten sind die Hochsitze sogar ausgeschildert. Z.B. 
habe ich hier in letzter Zeit an Bäumen rosa aufgesprühte Nummern und 
Pfeile gesichtet, die, wenn man ihnen folgte, zu Hochsitzen führten, die 
auch jeweils die Nummer trugen...




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread Andreas Schmidt

Hi Nop,

volle Zustimmung.

Am 14.03.2014 07:52, schrieb NopMap:
 - der Verfasser gibt keine Auskunft über seine Identität oder Legitimation
 dort überhaupt etwas zu fordern.

Selbst, wenn er Mitarbeiter des Forstamtes/Schießvereins/
Ehrenvorsitzender der Niedersächsischen Jägerschaft wäre, hätte seine
Forderung keine Legitimation.

Ich bringe mal das Beispiel der Militärfunkstation(en) in Frankreich.
https://de.wikipedia.org/wiki/Milit%C3%A4rische_Funkstation_Pierre-sur-Haute

2013 zwang der französische Inlandsgeheimdienst DCRI einen Mitarbeiter
der französischsprachigen Wikipedia unter Androhung von
Untersuchungshaft, den französischen Wikipedia-Artikel zur Funkstation
zu löschen.

Nach der Drohung mit Haft für einen Freiwilligen ist es eine Genugtuung,
dass der Wikipedia-Artikel nun in über deißig Sprachen existiert.
https://de.wikipedia.org/wiki/Streisand-Effekt#Weltweites_Internet

Die Herren Hobbyschlachter müssen sich halt damit abfinden, dass ihre
Freizeitbeschäftigung bei einem Teil der Bevölkerung nicht besonders
hoch angesehen ist.
Das widerrechtliche Beschädigen von Leitern, das ich ablehne, kann nicht
mit Geheimhaltung verhindert werden.

Ebenso wie Spaziergänger darauf achten müssen, nicht gegen Stahlseile
( http://abload.de/img/absperrung1ljsqy.jpg )
zu laufen, die von einem Jäger quer über den Weg gespannt wurden,
sollten Letztgenannte im eigenen Interesse die Stabilität ihrer
Schießstützpunkte vor dem Erklettern prüfen. Das hat nichts mit OSM zu
tun, das ist so.


Andreas




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread Falk Zscheile

Am 14. März 2014 08:56 schrieb Andreas Schmidt schmidt-postf...@freenet.de:

 Die Herren Hobbyschlachter müssen sich halt damit abfinden, dass ihre
 Freizeitbeschäftigung bei einem Teil der Bevölkerung nicht besonders
 hoch angesehen ist.
 Das widerrechtliche Beschädigen von Leitern, das ich ablehne, kann nicht
 mit Geheimhaltung verhindert werden.

 Ebenso wie Spaziergänger darauf achten müssen, nicht gegen Stahlseile
 ( http://abload.de/img/absperrung1ljsqy.jpg )
 zu laufen, die von einem Jäger quer über den Weg gespannt wurden,
 sollten Letztgenannte im eigenen Interesse die Stabilität ihrer
 Schießstützpunkte vor dem Erklettern prüfen. Das hat nichts mit OSM zu
 tun, das ist so.



Also bevor das jetzt hier zum Jägerbashing verkommt sollten wir
aufhören. Die Sachargumente wurden vorgetragen und haben breite
Zustimmung gefunden. In den letzten Beiträgen treten aber vermehrt
(also nicht in allen) Argumentationslinien wie (Alle) Jäger sind
schlecht, deshalb erst recht nicht auf. Das haben wir nicht nötig, um
unseren hier gefundenen Standpunkt zu vertreten.

Falk

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread Lothar Beck

Hallo Alle,

zur Frage welche Karten Hochsitze anzeigen.
Ich habe auf meinem Android Smartphone die App MapsWithMe:
http://mapswith.me/de/home installiert. Die verwendet OSM als Basis.
Rendert aber offensichtlich selbst, denn Hochsitze werden angezeigt.


Hallo Hartmut,

Am 13.03.2014 13:13, schrieb Hartmut Holzgraefe:
 On 03/13/2014 12:06 PM, Frederik Ramm wrote: Jetzt mal ganz blöd
 gefragt: werden Hochsitze auf den gängigen Karten überhaupt
 gerendert? Mir ist noch nie einer aufgefallen, das kann aber auch
 einfach daran liegen das hier in der Gegend keiner erfasst ist ...
 
 Selbst wenn ja: dann sehe ich darin immer noch keinen Beihilfe 
 Aspekt. Und wenn nicht: wenn sich da jemand tatsächlich die Mühe
 macht potentielle Anschlagsziele zB. mit OverPass herauszusuchen 
 dann wird derjenige entsprechende Informationen auch anderweitig 
 beschaffen können (zB aus History-Daten selbst wenn wir die 
 vorhandenen Hochsitz-Objekte löschen, oder auch aus ganz anderen 
 nicht-OSM Quellen)

Die All-in-one-Garmin-Map* stellt Hochsitze dar.
https://github.com/aiomaster/aiostyles/blob/master/basemap_style/points

Als ich mit OSM im Jahr 2011 angefangen habe, war das ein schönes
Feedback auf meinem Garmin. (Ich habe nämlich damals vor allem Feld-
und Waldwege sowie Hochsitze und andere Outdoor-Sachen gemappt).

So sieht es aus, wenn mehrere Hochsitz-Mapper (fast alle, die die
verlinkten Hochsitze gemappt haben, kenne ich persönlich):
http://overpass-turbo.eu/s/2Lo http://overpass-turbo.eu/s/2Lq

 Anders sähe das für mich erst zB. bei Nist- und Brutplätzen aus, 
 oder wenn Dinge wie Hier wächst ein Enzian engetragen werden ...

Nist- und Brutplätze sind oft (nicht bei allen Arten) temporär und
daher für OSM nur bedingt geeignet. :)

Viele Grüße

Michael


*) Derzeit scheint die AIO laut Wiki wieder nicht mehr aktuell zu sein.

- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTIh97AAoJEB87G9rMCMyIZf4P/0jSFjtbmlS7XepqKecKBPfE
zBVWp4gt0MVsEA0B6Z3qZgC1pvtqjXb1G4rZGw8ZrWJQgpHFN1jFxhPDnQzGRN1M
7X9dleev3u/Pd6Ti2hD58p5NOxFx0JNn4hzt2+iz0RfPd1zPu7crHC4uXXxXpK/B
7FswbdnrDMAelfaqYryEXGWAycLpLQ+22+wldbebyofiT1k6JzAZvHOuFiCR6W1m
BhyovWySZxpoaBUgGmDZkPhc5mniZYziPppUYhvaMxDRKD/P5aYxlpx6WNvYbXcC
XMo1/5CzapWjV7c0ffReHYyvKqDuQLsbHvBQYv9oQAf9umVtrcGgEfqNsd0cNd0/
qqretTwKXTlc7dG/0a5Bj3yAFAhUzATFxPiGZ3OX60M3nZPPuDnxJXuTdBiKcfhz
PVL2hFIc1eMmSZgS/bHlsgVeQ8RWTwSYd4428q7FNAZLHx5RrXnzdxduJqku5x+q
ZXc9IXT5AuNr2Y04lTeRX0qqsAXwWz+KPUKxLvXVz1oNj4rw8hqGAYweRSaVyAUI
2DslBP0OtjSHaM4jpYJkleZDSyP+/M3JkUI5RO2D0gviV5dxA4AY12+6CG5HPnTC
oWxoo4r2pXXmFx+iefY9NIagyxeWw1S6HkJGChrYDzr2PNx8cZgd6o0mVkR3xdY9
lcGI1zI0Gjtkmg7ptr5K
=2F/q
-END PGP SIGNATURE-

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread Hartmut Holzgraefe

On 03/14/2014 09:14 AM, Lothar Beck wrote:

 Nist- und Brutplätze sind oft (nicht bei allen Arten) temporär und
 daher für OSM nur bedingt geeignet. :)

ich stoße hier im Wald immer wieder mal auf fest installierte
Nistkästen und -hilfen, die meisten davon mit einer deutlich
lesbaren Nummerierung ... trage die aber trotzdem nicht ein
weil ich potentiellen Nesträubern dann doch nicht zuarbeiten
möchte ... im Gegensatz zu Hochsitzen sehe ich in diesem
Fall schon eher ein ähnliches Schutzinteresse wie zB. bei
Frauen- oder Mädchenhäusern die auch aus gutem Grund nicht
findbar sein wollen ... ok, der Vergleich hinkt, wie alle
Vergleich, aber ich denke es ist klar was ich meine und wo
ich persönlich die Grenze sehe, auf jeden Fall eindeutig
noch nicht bei Hochsitzen (oder Hochspannungsmasten, da war
ja damals auch mal was ...)

-- 
hartmut

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread Andreas Neumann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 14.03.2014 08:56, schrieb Andreas Schmidt:
 [...] Die Herren Hobbyschlachter [...]

Ich verbitte mir eine solche Ausdrucksweise in öffentlichen
Diskussionen. Man mag zur Jagd stehen wie man will, aber man sollte
auch Menschen, deren Hobby man ablehnt, mit Respekt begegnen. Du
willst ja auch, dass uns Mappern Respekt entgegen gebracht wird.

Viele Grüße,
Andreas

- -- 
Andreas Neumann
http://map4Jena.de
http://Stadtplan-Ilmenau.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQGcBAEBAgAGBQJTItiQAAoJENEKAxYRlUN9WjEL/14h2UfyBlnEXKHn8HuvtMKI
tOJ3/m0LdBZY0d25gL7LkdeCpOqrGYdo3aOYAjfaC1kgLv6s6UyFqV5/FrUansYz
sAva65y8RpASMClP5yWXGga7J+2Iw0/16W5oa/14BCHqtwYVecOfHKEdiawBtAsa
Fu0TtI6gh4EEkw4OfH0QaFqOGhdNu78bkjqpNLB9IApAp7kmzuft1dscbppnSnJP
SyzoiyANmWy5LBlCVwEu0rMN4b9HNp+9unBQEbmUldEtIdOjUu58xG1R9xxsStw1
wPrES+SrKNDpVDQ303TxADZFf+JkDBp1G0sQw3XokHmfCMzjxgSEQ2058CL8Kz+o
z8pG2VMFWjFQ34KhhqNWE2Sf1kdLDW8ZViG8H8ginqfpPIVHCfygbR2DkXJ/uPcd
sFAQMOVW0ow7+/Sc1lFhbneka1648Dp6MbdB31cIxBdlL1yam3gPLApDMmIU61vg
vRBHgu9TZCZNJ+Wt1mE8qqs/MXsklx07YQe72+0PrQ==
=KlSX
-END PGP SIGNATURE-

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Thread tshrub


Am 13.03.2014 22:14, schrieb Michael Reichert:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo Frederik,

Am 13.03.2014 20:21, schrieb Dirk Sohler:

Frederik Ramm schrieb:

Ich weiss nicht ganz, wie ich darauf reagieren soll.


Gar nicht.


Hat er sich überhaupt mit mehr Informationen als seinem Benutzernamen
bei dir gemeldet? Behörden machen auch in der Regel nichts, wenn man
sich als superjaege...@yahoo.com bei ihnen meldet.


So lange du die Hochsitze nicht betrittst, und der Wald öffentlich
  zugänglich ist, gibt es nichts, was gegen das Erfassen von
Hochsitzen spricht, außer die Einzelmeinung desjenigen, der dich
angeschrieben hat.


Wir erfassen ja mittlerweile auch die Farbe von Gebäuden, die
Privateigentum sind. Solange die Erfassung legal ist, gibt es IMHO
keinen Grund das zu löschen.
m.E. kann man bei uns alles erfassen, was von öffentlichem bzw. 
freigegebenen Grund aus zu sehen ist.
Lediglich was man nur von privatem Grund aus sehen kann, mag 
eingeschränkt verfügbar sein. Da gab es vor einigen Jahren eine 
Diskussion bzgl. Fotorechten von Objekten in Sanssouci: die Fotos durfte 
man nicht so einfach nutzen / verkaufen, weil nur aus dem Park (Eintritt 
etc.) zu sehen / aufgenommen. (Weiß aber nicht, obs abschließend 
entschieden ist)


So einen Hochsitz: natürlich kann man den kartieren. Die Wälder sind 
hier betretbar und ein Hochsitz ist auch eine Art Landmarke.
Gegen Rowdytum muss sich der Jäger woanders / an anderer Stelle 
einsetzen. Freizeitheime oder so ...


Grüße








Ich finde das aber mit den Straftaten ein bisschen komisch, das
klingt, als wollte man den Mapper unter Druck setzen und ihn zum
Mittäter machen, wenn er nicht freiwillig seine Hochsitze
löscht...


Genau das. Daher: Einfach ignorieren. Soll derjenige doch klagen,
mal sehen, wie weit er kommt :)


Nicht antworten, ignorieren, aussitzen und abwarten, bis Gras darüber
gewachsen ist, finde ich die beste Lösung. Wenn es ihm wichtig ist,
wird er sich bestimmt nochmal melden. Also einfach gar nicht
antworten, nicht ablehnen und nicht bestätigen/zustimmen.

Das schlimmste, was passieren kann, ist, dass er (falls er überhaupt
Jäger ist), von einem angesägten Hochsitz stürzt und dann zur
Lokalzeitung rennt und die dann titelt:

Computerfreaks helfen militanten Tierschützern oder
Computerfreaks sabotieren Hochsitze :)

Hoffen wir mal, dass er hier nicht mitliest und diese öffentliche
Diskussion nicht über Google findet.

Sollte er, weil du nicht antwortest, selber aktiv werden, hast du
schon seit mehreren Monaten genügend Gründe für eine endgültige
Sperre. http://www.openstreetmap.org/user_blocks/396

Wie lange sind wir dem Schleswiger hinterhergejagt?
http://forum.openstreetmap.org/viewtopic.php?id=16891
Ok, es war nervenaufreibend und sollte vermieden werden.

Fazit: Ignoriere es, erfreue dich der weiteren Antworten hier und
kümmer dich um wichtigere Dinge.

Viele Grüße

Michael





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] SOTM-EU - Vorträge einreichen

2014-03-14 Thread Andreas Labres

Hallo!

Bitte Vorträge für die SOTM-EU einreichen, die Frist endet am 17. März!

Details:   https://sotm-eu.org/en/pages/cfp

/al


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten