date:20140828

There's one fundamental question about wikidata tags; how do you tag
multiple objects that have the same wikidata tag? For example, a wikidata
entry about a church and a connected monastery. When I was writing the
Wikidata proposal on our wiki, I've put a rule that only one object in OSM
can have the same wikidata=* tag. So when there are more ways in OSM that
represent one element in Wikidata, we should put them in a relation and put
the wikidata tag in the relation.

Since then I changed my opinion a bit, but I'm not sure if we should just
put wikidata=* on all ways, or if we should invent a new tag,
wikidata:part=* and put that tag on all the objects.

The problem with putting wikidata=* on several objects is that people could
come to an idea to put wikidata=Q3947 (entry about houses) on all houses,
or wikidata=12280 on all bridges. That's why I think wikidata:part=* is the
best way to deal with this, and make multiple wikidata tags with the same
value invalid.

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

Re: [OSM-talk] Own wikipage for every single speed limit??

2014-08-28 Thread Jochen Topf

On Do, Aug 28, 2014 at 11:35:59 +0100, Craig Wallace wrote:
 On 2014-08-28 11:20, Maarten Deen wrote:
 On 2014-08-28 12:10, Richard Z. wrote:
 Hi,
 
 noticed that there is
 
 https://wiki.openstreetmap.org/w/index.php?title=Tag:maxspeed%3D20redirect=no
 
 and a few more speeds - does it make any sense to have such
 pages around?
 
 If you take a look at the what links here link from the wiki you'll
 see what they are used for. In this case almost all pages about Kosmos
 rules, but also some other.
 The thing is that if you add something as a tag in wikipedia
 ({{tag|maxspeed|15}}), you'll automatically get a link to a wiki page
 for that tag. And since it is pretty senseless to have a seperate page
 for every different speed limit, they are redirected to a general page
 about the maxspeed tag.
 
 I would leave them in.
 
 For the wiki, you should use the tag template like {{tag|maxspeed||20}}
 ie 2 | vertical bars after the key. Then it doesn't create a link to the
 value.
 
 But there's nothing wrong with redirect pages on the wiki anyway. It helps
 people find the correct page, and avoids creating duplicates.

Redirect pages can have a bad effect, though. Taginfo will show if a wiki page
exists for a key or tag. Taginfo can't know why there is a redirect. Is this a
case where the redirect directs from a typo page to the real page or is
this a case where, like in the maxspeed case, several pages for totally
good tags have been rolled into one. So taginfo shows them all the same and
might lead people into thinking the typo key is the real one, if they don't
click through to the page.

The problem behind this is that there is no way to mark the reason why there is
a redirect. It could be old now discontinued name, or common misspelling,
or this page would be basically a copy of this other one, so look there, or
probably some other reasons. Redirects hide this information, that could be
written down on the page instead. So I think redirects should be avoided. In
particular, misspellings would be better handled by having a slightly fuzzy
search (not sure how good MediaWiki is for that).

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Jochen Topf

On Do, Aug 28, 2014 at 01:23:21 +0200, Janko Mihelić wrote:
 There's one fundamental question about wikidata tags; how do you tag
 multiple objects that have the same wikidata tag? For example, a wikidata
 entry about a church and a connected monastery. When I was writing the
 Wikidata proposal on our wiki, I've put a rule that only one object in OSM
 can have the same wikidata=* tag. So when there are more ways in OSM that
 represent one element in Wikidata, we should put them in a relation and put
 the wikidata tag in the relation.
 
 Since then I changed my opinion a bit, but I'm not sure if we should just
 put wikidata=* on all ways, or if we should invent a new tag,
 wikidata:part=* and put that tag on all the objects.
 
 The problem with putting wikidata=* on several objects is that people could
 come to an idea to put wikidata=Q3947 (entry about houses) on all houses,
 or wikidata=12280 on all bridges. That's why I think wikidata:part=* is the
 best way to deal with this, and make multiple wikidata tags with the same
 value invalid.

There is no way to make something like that invalid on OSM. So if only a few
people would use the same wikidata tag on multiple OSM objects, everybody
using those tags will have to deal with it to capture those cases. In the end
you make things more complicated with the wikidata:part without any real
benefit.

One should hope that people who start tagging generic terms will get slapped
anyway. Tag naming will not prevent that.

And I am glad you changed your opinion on the relation thing. :-)

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Andy Mabbett

On 28 August 2014 12:04, SomeoneElse li...@mail.atownsend.org.uk wrote:
 On 27/08/2014 22:15, Andy Mabbett wrote:

 Wikidata has data on each of these entities which either
 isn't in OSM (who's the mayor of this town/ vicar of this church?)

 OK - not sure how that's a benefit to OSM as such, though
 I'm sure people could do useful unexpected things with
 those links.

That's the point - the benefit is to OSM's users, whcih in turn
benefits OSM in the same way any other enhancements does - making it
more useful, attracting more contributors, etc.

 or which acts as a sanity check for what is in OSM (We can
 generate lists where the two disagree, for humans to check
 and fix).

 That sounds useful, but sounds like in theory someone
 could generate a list rather than actually volunteering to do so.

Of course it's in theory - we haven't applied the tags, yet.

 Wikidata has multi-lingual labels for many objects, which OSM
 renderers can fetch via the Wikidata link.

 That's definitely useful.  It would allow us to split the
 verifiable on the ground stuff from the other stuff -
 it should save us having 190 names for Berlin that mostly
 say Berlin.

Indeed.

 Another one (mentioned on IRC) is a way to get up
 to date population data for places - data that couldn't or
 shouldn't be in OSM for licence reasons,
 or (like your vicars example) is continuously changing
 and not easily verifiable.

 What disadvantages do you forsee?

 Maintainability, as has already been mentioned.  With any
 import there has to be a plan for how do we make sure this
 data stays up to date, and I'm not seeing that yet.

I'm not anticipating many changes; this import gives a leg-up to a
human process.

 Another issue is with dodgy data on either the OSM or the
 wikidata side. I've already mentioned non-existing villages
 in wikipedia, but there are also examples where the OSM
 side's iffy too, which could result in a false match.

I addressed that in a earlier email

 I think the issues raised have been addressed; which do
 you feel have not been?

 Specifally, comments such as In my opinion, the risks of
 doing this automatically are just too high, +1 to not import
 blindly but require human confirmation and that's why I
 was asking how you proposed to measure it in those
 threads.

The former pair are vague hand-waving; more specific points have been
addressed, which covered such things (and there is no plan for blind
importing). The latter was also addressed.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Edward Betts

Janko Mihelić jan...@gmail.com wrote:
 There's one fundamental question about wikidata tags; how do you tag
 multiple objects that have the same wikidata tag? For example, a wikidata
 entry about a church and a connected monastery. When I was writing the
 Wikidata proposal on our wiki, I've put a rule that only one object in OSM
 can have the same wikidata=* tag. So when there are more ways in OSM that
 represent one element in Wikidata, we should put them in a relation and put
 the wikidata tag in the relation.
 
 Since then I changed my opinion a bit, but I'm not sure if we should just
 put wikidata=* on all ways, or if we should invent a new tag,
 wikidata:part=* and put that tag on all the objects.

For now I've side stepped this problem. If you look at an institution like a
hospital, university or school you'll often find multiple buildings, some
might include a name and be tagged amenity=hospital/university/school. If my
code spots two or more nearby items with the correct tags and matching names
it skips them, so I don't have to deal with multiple OSM items having the same
wikidata tag.

I can also detect if there are two nearby items with the same name but
different tagging. I found an article on Wikipedia that was in the categories
for bridge and monument. In OSM we have a 'way' to represent the bridge and a
'node' in the middle of the bridge for the monument. I skip these as well,
there are just over 200 of them.
-- 
Edward.

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Andy Mabbett

On 28 August 2014 12:23, Janko Mihelić jan...@gmail.com wrote:

 The problem with putting wikidata=* on several objects is
 that people could come to an idea to put wikidata=Q3947
 (entry about houses) on all houses, or wikidata=12280 on
 all bridges.

Jochen has already answered that well, but we should also put those
relationships (e.g. bridge=yes == Q12280) onto the Wiki page which
defines the tag; preferably as a parameter in {{KeyDescription}}.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Own wikipage for every single speed limit??

2014-08-28 Thread Andreas Goss


The problem behind this is that there is no way to mark the reason why there is
a redirect.


Well, there is a little trick ;)

http://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dalmaction=edit

http://taginfo.openstreetmap.org/tags/amenity=alm#wiki
__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 14:41 GMT+02:00 Edward Betts edw...@4angle.com:


 For now I've side stepped this problem. If you look at an institution like
 a
 hospital, university or school you'll often find multiple buildings, some
 might include a name and be tagged amenity=hospital/university/school. If
 my
 code spots two or more nearby items with the correct tags and matching
 names
 it skips them, so I don't have to deal with multiple OSM items having the
 same
 wikidata tag.


Most of this cases are probably just bad tagging, but it's possible some of
them indeed are multiple objects described in an article. It would be
useful to make a KeepRight style map with such problematic objects.


 I can also detect if there are two nearby items with the same name but
 different tagging. I found an article on Wikipedia that was in the
 categories
 for bridge and monument. In OSM we have a 'way' to represent the bridge
 and a
 'node' in the middle of the bridge for the monument. I skip these as well,
 there are just over 200 of them.


Bridges are bit of a grey area, is a highway with bridge=yes really a
bridge, or is it a highway which has a property of being on a bridge? I
think we should map these notable bridges as an area with man_made=bridge
and put the tag on that.
The very first example of a bridge on your list is already problematic:

http://www.openstreetmap.org/way/5620489

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Pieren

On Thu, Aug 28, 2014 at 2:25 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 OK - not sure how that's a benefit to OSM as such, though
 I'm sure people could do useful unexpected things with
 those links.

 That's the point - the benefit is to OSM's users, whcih in turn
 benefits OSM in the same way any other enhancements does - making it
 more useful, attracting more contributors, etc.

Er, I'm an OSM user and I don't see any benefit for myself but I see
definitely benefits for wikipedians...
The example saying that missing translations could be then found in
wikidata is telling me the opposite : it will surely not call people
to contribute in OSM but rather directly in wikidata !

Pieren

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Andrew Guertin


On 08/27/2014 12:47 PM, Edward Betts wrote:

I'd like to annotate these 70k objects in OSM with a Wikidata tag
automatically.


I like the sound of this. Personally, I think it adds value, and having 
looked at the code your matching criteria sound good.


There are a couple of things it would make me happy to see before you go 
through with this:



1: Elsewhere in this thread it was mentioned that there are 22000 
wikidata ids in OSM currently. Are there any objects which currently 
have a wikidata id that your code would assign a different id to? 
Similarly, are there any instances where your code would assign a 
wikidata id to something and a different object in OSM already has that 
wikidata id?


I assume your plan is to not modify these, but I'm more concerned with 
seeing how well your code matches what's already in OSM as a 
verification tool.



2: You mention elsewhere in this thread that the maximum distance 
difference between the wikidata location and the osm object is 400 
meters. How was this number arrived at? Could you make a list of matches 
including and sorted by the distance difference for people to look at? I 
think it's worth it for interested people to be able to independently 
verify at what distance the accuracy declines and what a good cutoff is.


It might be good to also include in that list what type of feature 
something is. If you're comparing using centroids, more leniency might 
be in order for, e.g., a large lake than a small building.



To be honest, I still support this import even without these 
verification tools, but it would make me very happy to see them.


--Andrew

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

[OSM-talk] OSM goes (almost) in the 4ht dimension

2014-08-28 Thread Christian Quest

For the impatient having red/cyan 3D glasses, first stop is :
http://tile.openstreetmap.fr/~cquest/leaflet/4d.html

otherwise:
https://cquest.hackpad.com/OpenStreetMap-goes-in-the-4th-dimension--ju3XWhj2qAV

Have fun ! (OSM's second law)
-- 
Christian Quest - OpenStreetMap France
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Edward Betts

Janko Mihelić jan...@gmail.com wrote:
 Bridges are bit of a grey area, is a highway with bridge=yes really a
 bridge, or is it a highway which has a property of being on a bridge? I
 think we should map these notable bridges as an area with man_made=bridge
 and put the tag on that.
 The very first example of a bridge on your list is already problematic:
 
 http://www.openstreetmap.org/way/5620489

That way represents both the street and the bridge. I don't think there is
any problem with adding a tag for the matching item on wikidata.

http://wikidata.org/wiki/Q4547392

-- 
Edward.

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

[OSM-talk] Introducing Fix waterway direction

2014-08-28 Thread Peter Barth

Hi all,

I created a new challenge for MapRoulette: Fix waterway direction.

As the waterway's direction in OSM denotes the direction of the water's
flow, I started to compare them to SRTM. This leads to more than 1 
million wrong directions for Europe only. Many times SRTM is right,
however, due to data errors, not every time. That's why I created this 
challenge.

A more detailed description can also be found on my user diary here:
http://www.openstreetmap.org/user/Peda/diary/23632

I started with the really easy ones and only Europe for now. I will 
upload further tasks soon, worldwide coverage will follow, too.

Hope you enjoy this challenge,
Peda

-- 

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

Re: [OSM-talk] Introducing Fix waterway direction

2014-08-28 Thread Christoph Hormann

On Thursday 28 August 2014, Peter Barth wrote:
 Hi all,

 I created a new challenge for MapRoulette: Fix waterway direction.

 As the waterway's direction in OSM denotes the direction of the
 water's flow, I started to compare them to SRTM. This leads to more
 than 1 million wrong directions for Europe only. Many times SRTM is
 right, however, due to data errors, not every time. That's why I
 created this challenge.

 [...]

Great to see the waterways are getting some attention. Does this only 
analyze SRTM elevations at start and end point or are the surrounding 
waterways considered?  If a waterway meets another waterway at one side 
but is unconnected at the other for example this is usually a strong 
indicator for the direction independent of the elevations data (which 
is only helpful usually in mountain areas).

In terms of usability it would of course be good if you could see the 
direction in MapRoulette so you can verify the data without actually 
loading it in the editor.

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

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

Re: [OSM-talk] Introducing Fix waterway direction

2014-08-28 Thread Peter Barth

Hi,

Christoph Hormann schrieb:
 Great to see the waterways are getting some attention. Does this only 
 analyze SRTM elevations at start and end point or are the surrounding 
 waterways considered?  

currently start and end point only. I have code to do more, but for the
easy tasks that was not necessary as I have a fairly high number of true
positives.

 If a waterway meets another waterway at one side 
 but is unconnected at the other for example this is usually a strong 
 indicator for the direction independent of the elevations data (which 
 is only helpful usually in mountain areas).

Actually I found many streams where start and end point are not
connected to anything at all. However, for those cases (not mountain
areas) the aerials didn't help neither in most cases ;) But as I'd like
to get a mostly complete waternetwork for another project, I'm planning
on extending the challenge at some point.

 In terms of usability it would of course be good if you could see the 
 direction in MapRoulette so you can verify the data without actually 
 loading it in the editor.

Serge suggested this, too. But I did never understand what the direction
would tell the user? Does it denote the current way's direction or the
supposed correct direction? How would the user know? And my biggest
concern is, that in many cases you need aerial anyway to be really sure.

Anyways, would be happy to add this, once I got, how this should be done
:)

Peda

-- 

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

Re: [OSM-talk] Introducing Fix waterway direction

2014-08-28 Thread Malcolm Herring


On 28/08/2014 19:49, Peter Barth wrote:

A more detailed description can also be found on my user diary here:
http://www.openstreetmap.org/user/Peda/diary/23632


Your statement that canals may flow uphill is incorrect. Where canals 
pass over a summit, the water supply is fed into the topmost pound and 
then flows in both directions (i.e. downhill) from that feed. Therefore 
the water flow should always match a topological analysis. In the case 
of contour canals, no actual water flow may take place, therefore the 
direction of the way would be arbitrary.


Also, for navigational reasons, canal administrations [in Europe 
(CEVNI)] have to define a left  right bank to determine the colours of 
buoys  nomenclature of signage. These may conflict with the actual 
water flow, since the left/right choice is arbitrary. Likewise the 
direction of the way.



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

Re: [OSM-talk] Introducing Fix waterway direction

2014-08-28 Thread Christoph Hormann

On Thursday 28 August 2014, Peter Barth wrote:
 ]...] But as I'd
 like to get a mostly complete waternetwork for another project, I'm
 planning on extending the challenge at some point.

If you are hoping for a complete network right from the OSM database 
without post processing you have a long way ahead of you...

  In terms of usability it would of course be good if you could see
  the direction in MapRoulette so you can verify the data without
  actually loading it in the editor.

 Serge suggested this, too. But I did never understand what the
 direction would tell the user? Does it denote the current way's
 direction or the supposed correct direction? How would the user know?
 And my biggest concern is, that in many cases you need aerial anyway
 to be really sure.

Well - cases like

http://maproulette.org/#t=waterways-direction/8300823723664637270

are pretty clear cut - no need for other data.  If you'd be able to 
switch to a background map with relief rendering like the cyclemap even 
less clear cases can often be properly determined.  It is also a matter 
of motivation i think - if you can clearly see the error you are much 
more motivated to fix it.

Of course showing the direction of the other waterways around would be 
very useful - but probably difficult to implement.

I would always show the currently mapped direction - so the potential 
answer 'this is not an error' matches that rendering.

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

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

Re: [OSM-talk] Introducing Fix waterway direction

2014-08-28 Thread Peter Wendorff

Am 28.08.2014 um 21:48 schrieb Peter Barth:
 Hi,
 
 Christoph Hormann schrieb:
 Great to see the waterways are getting some attention. Does this only 
 analyze SRTM elevations at start and end point or are the surrounding 
 waterways considered?  
 
 currently start and end point only. I have code to do more, but for the
 easy tasks that was not necessary as I have a fairly high number of true
 positives.
 
 If a waterway meets another waterway at one side 
 but is unconnected at the other for example this is usually a strong 
 indicator for the direction independent of the elevations data (which 
 is only helpful usually in mountain areas).
 
 Actually I found many streams where start and end point are not
 connected to anything at all. However, for those cases (not mountain
 areas) the aerials didn't help neither in most cases ;) But as I'd like
 to get a mostly complete waternetwork for another project, I'm planning
 on extending the challenge at some point.
 
 In terms of usability it would of course be good if you could see the 
 direction in MapRoulette so you can verify the data without actually 
 loading it in the editor.
 
 Serge suggested this, too. But I did never understand what the direction
 would tell the user? Does it denote the current way's direction or the
 supposed correct direction? How would the user know? And my biggest
 concern is, that in many cases you need aerial anyway to be really sure.
 
 Anyways, would be happy to add this, once I got, how this should be done
 :)
You may add arrows in both directions, color-coded for assumed and
current (and explained in the challenge description on the top right)

regards
Peter

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

Re: [OSM-talk] OSM goes (almost) in the 4ht dimension

2014-08-28 Thread Cristian Consonni

2014-08-28 19:34 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:
 For the impatient having red/cyan 3D glasses, first stop is :
 http://tile.openstreetmap.fr/~cquest/leaflet/4d.html

 otherwise:
 https://cquest.hackpad.com/OpenStreetMap-goes-in-the-4th-dimension--ju3XWhj2qAV

You, sir, are a genius.

Cristian

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

Well, you should at least take preference to man_made=bridge[1] if there is
any. Highways can be split, just like in my example, and then that looks as
if there are two bridges. What if there is a footway running besides the
road? Should it also get the wikidata tag?

If we start putting wikidata=* on highways, there should be an initiative
to add man_made=bridge on those and move the tag there. At least with
bridges that have more than one highway on them.

The same story is with tunnels, although I see there is no page with
man_made=tunnel yet.

[1] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbridge


2014-08-28 19:42 GMT+02:00 Edward Betts edw...@4angle.com:

 Janko Mihelić jan...@gmail.com wrote:
  Bridges are bit of a grey area, is a highway with bridge=yes really a
  bridge, or is it a highway which has a property of being on a bridge? I
  think we should map these notable bridges as an area with man_made=bridge
  and put the tag on that.
  The very first example of a bridge on your list is already problematic:
 
  http://www.openstreetmap.org/way/5620489

 That way represents both the street and the bridge. I don't think there is
 any problem with adding a tag for the matching item on wikidata.

 http://wikidata.org/wiki/Q4547392

 --
 Edward.

 ___
 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] Adding Wikidata tags to 70k items automatically

Here's another example:

http://www.openstreetmap.org/way/34012792

This railroad track will get the wikidata tag, the other track and footway
won't. And even the track that gets the tag, isn't the whole length of the
bridge. And I didn't even look that hard. I found problems on 2 out of 6
bridges I clicked.

I'm not against your import, I think your work on this is great, but the
bridge part is just not that simple.

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Edward Betts

Janko Mihelić jan...@gmail.com wrote:
 Here's another example:
 
 http://www.openstreetmap.org/way/34012792
 
 This railroad track will get the wikidata tag, the other track and footway
 won't. And even the track that gets the tag, isn't the whole length of the
 bridge. And I didn't even look that hard. I found problems on 2 out of 6
 bridges I clicked.
 
 I'm not against your import, I think your work on this is great, but the
 bridge part is just not that simple.

Thanks, we might need to skip bridges and tunnels.

-- 
Edward.

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread SomeoneElse


On 28/08/2014 13:25, Andy Mabbett wrote:

I'm not anticipating many changes; this import gives a leg-up to a
human process.


(as has been mentioned before) wikidata may not change, but OSM data 
surely does.  If I split a way that has a wikidata tag, how do I know 
which of the two resulting elements should have the wikidata tag?





Another issue is with dodgy data on either the OSM or the
wikidata side. I've already mentioned non-existing villages
in wikipedia, but there are also examples where the OSM
side's iffy too, which could result in a false match.

I addressed that in a earlier email


I can only find is you saying That sounds much like an edge case in 
https://lists.openstreetmap.org/pipermail/talk/2014-August/070635.html , 
which doesn't sound like addressing the issue at all.  If that wasn't it 
would it be possible to provide a link?



I think the issues raised have been addressed; which do
you feel have not been?

Specifally, comments such as In my opinion, the risks of
doing this automatically are just too high, +1 to not import
blindly but require human confirmation and that's why I
was asking how you proposed to measure it in those
threads.

The former pair are vague hand-waving; more specific points have been
addressed, which covered such things (and there is no plan for blind
importing). The latter was also addressed.

I'd disagree that the first two are mere hand-waving.  They sound like 
genuine mappers' opinions, perhaps based on previous imports. The only 
addressing of the third point I could see was in 
https://lists.openstreetmap.org/pipermail/talk-gb/2014-June/016113.html 
on talk-GB..


As I said before, I'm fairly agnostic about wikidata being in OSM 
(though concerned that it might just get dumped in with no verifiability 
and no plan for maintenance).  However, what's being proposed is a 
worldwide import, and any addressing of issues needs to be done here 
rather than on a local list that won't have been read by most people 
affected.


Cheers,

Andy

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

2014-08-28 Thread Martin Koppenhoefer



 Il giorno 29/ago/2014, alle ore 01:12, SomeoneElse 
 li...@mail.atownsend.org.uk ha scritto:
 
 
 (as has been mentioned before) wikidata may not change, but OSM data surely 
 does.  If I split a way that has a wikidata tag, how do I know which of the 
 two resulting elements should have the wikidata tag?


You generally will know. When you split a way you will do it for a reason, and 
you will have to check for all tags on the way on which of the new ways you 
will keep them, including the wikidata tag. Like any other information also 
wikidata tags will raise the complexity, there is no difference (assuming here 
that you will have linked information about the wikidata object to base your 
judgement on, besides the cryptic reference number, stuff like a name or the 
kind of object).

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

[OSM-talk] Field Papers web app source code hosted at GitHub currently subject to DMCA takedown and not accessible

2014-08-28 Thread Joseph R. Justice

[Intentionally posted to both talk@ and talk-us@.  -- J]

I just now happened to try to access my personal fork of the repository for
the source code for the Field Papers (http://fieldpapers.org/) web app site
(said repository of source code can usually be found at
https://github.com/stamen/fieldpapers), only to find that the fork was
currently not accessible due to a DMCA takedown, apparently related to the
presence of font data originally created by Monotype Corporation and/or
related companies and organizations.

Because of this DMCA takedown, the master repository of the source for
Field Papers, my personal fork of it, and the repository for the source of
the software Field Papers was derived from are all currently inaccessible
at GitHub.  (Many other things unrelated to Field Papers or OSM in general
are also being affected by this.)

Information about the DMCA takedown and what is affected by it, and what
the takedown is complaining about, can be found at
https://github.com/github/dmca/blob/master/2014-08-27-Monotype-Imaging.md .

Does Stamen Design (as the organization responsible for creating and
presumably maintaining the Field Papers web app at http://fieldpapers.org/
and the software behind the web app) know about this yet?  Are they doing
something about it?  I wouldn't be surprised if the DMCA takedown is
extended to the web app site itself at some point, if something isn't done
about this.

I have taken the liberty of CCing Stamen Design at i...@stamen.com with
this letter, to make sure they are aware of what's going on (especially if
they are not yet aware of it).

Thank you for giving me a moment of your time.  I hope you find this of
some use, interest.  I look forward to learning more about this situation
as it develops and is (hopefully) resolved in a desirable fashion in the
near future.

Joseph



PS: I still cannot access my own attempt at an account at the Field Papers
web app site, but that's not relevant to the issue here.  If I ever get off
my lazy butt and write some patches to their code for the site to fix this
sort of thing (which is why I'd created a fork in the first place), then
I'd be able to get at my account w/o needing them to do something.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Tiger 2014 Shapfiles just released

2014-08-28 Thread Hans De Kryger

Released August 19, 2014 -

https://www.census.gov/geo/maps-data/data/tiger-line.html

Anyone know if they will be added to I.D editor anytime soon?

*Regards,*

*Hans*


*http://www.openstreetmap.org/user/TheDutchMan13
http://www.openstreetmap.org/user/TheDutchMan13 *
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Introducing Fix waterway direction

2014-08-28 Thread Russ Nelson

Not to brag, but New York State is already all done. I mean, there may
be one or two mistakes, but when I was entering all of the streams
listed in Wikipedia for NY, I set the flow direction properly. So if
you have a way to exclude New York, you will have more productive
users.
-russ

Peter Barth writes:
  Hi all,
  
  I created a new challenge for MapRoulette: Fix waterway direction.
  
  As the waterway's direction in OSM denotes the direction of the water's
  flow, I started to compare them to SRTM. This leads to more than 1 
  million wrong directions for Europe only. Many times SRTM is right,
  however, due to data errors, not every time. That's why I created this 
  challenge.
  
  A more detailed description can also be found on my user diary here:
  http://www.openstreetmap.org/user/Peda/diary/23632
  
  I started with the really easy ones and only Europe for now. I will 
  upload further tasks soon, worldwide coverage will follow, too.
  
  Hope you enjoy this challenge,
  Peda
  
  -- 
  
  ___
  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] Field Papers web app source code hosted at GitHub currently subject to DMCA takedown and not accessible

2014-08-28 Thread Joseph R. Justice

[The following is forwarded to the lists on behalf of Mr. Fitzsimmons at
his request.  Apparently, his initial attempt to respond to my message to
talk@ and talk-us@ was bounced and/or held for moderation because he does
not subscribe to the lists.  I'd like to emphasize that his response was
sent some 40 minutes after my original message went out; Stamen Design did
respond quickly once notified.  -- J]



-- Forwarded message --
From: Seth Fitzsimmons s...@stamen.com
Date: Thu, Aug 28, 2014 at 10:41 PM
Subject: Re: Field Papers web app source code hosted at GitHub currently
subject to DMCA takedown and not accessible
To: jayare...@gmail.com
Cc: talk...@openstreetmap.org, talk@openstreetmap.org, jayare...@gmail.com,
e...@stamen.com


We did not know about this; thank you for making us aware.  Apparently DMCA
takedowns don't result in corresponding email notifications.

Here's what we're planning on doing:

* Eric Gelinas (cc'd) has contacted GitHub about getting the repository
reinstated so that we can push up a sanitized version and have the takedown
taken down. Hopefully this will be straightforward; if not, we may have to
get our lawyer involved and file a counter-notice to the effect that we're
no longer infringing.
* Eric is in the process of removing the offending content (Helvetica,
ironically enough) from the repo.
* I'm letting Mike Migurski know, as his walkingpapers repo is the parent,
and there may be complications associated with fieldpapers being a fork.

This is what it means for users of the repo / forks:

* You'll need to re-clone stamen/fieldpapers, as none of the commit IDs
will line up after sanitization.

This is what it means for users of Field Papers:

* Nothing. The offending content is not accessible via the web site, so
there's no justification for a DMCA takedown of Field Papers itself.

Thanks for your understanding.

seth


On Thu, Aug 28, 2014 at 7:02 PM, Joseph R. Justice jayare...@gmail.com
wrote:

[Intentionally posted to both talk@ and talk-us@.  -- J]

 I just now happened to try to access my personal fork of the repository
 for the source code for the Field Papers (http://fieldpapers.org/) web
 app site (said repository of source code can usually be found at
 https://github.com/stamen/fieldpapers), only to find that the fork was
 currently not accessible due to a DMCA takedown, apparently related to the
 presence of font data originally created by Monotype Corporation and/or
 related companies and organizations.

 Because of this DMCA takedown, the master repository of the source for
 Field Papers, my personal fork of it, and the repository for the source of
 the software Field Papers was derived from are all currently inaccessible
 at GitHub.  (Many other things unrelated to Field Papers or OSM in general
 are also being affected by this.)

 Information about the DMCA takedown and what is affected by it, and what
 the takedown is complaining about, can be found at
 https://github.com/github/dmca/blob/master/2014-08-27-Monotype-Imaging.md
 .

 Does Stamen Design (as the organization responsible for creating and
 presumably maintaining the Field Papers web app at http://fieldpapers.org/
 and the software behind the web app) know about this yet?  Are they doing
 something about it?  I wouldn't be surprised if the DMCA takedown is
 extended to the web app site itself at some point, if something isn't done
 about this.

 I have taken the liberty of CCing Stamen Design at i...@stamen.com with
 this letter, to make sure they are aware of what's going on (especially if
 they are not yet aware of it).

 Thank you for giving me a moment of your time.  I hope you find this of
 some use, interest.  I look forward to learning more about this situation
 as it develops and is (hopefully) resolved in a desirable fashion in the
 near future.

 Joseph



 PS: I still cannot access my own attempt at an account at the Field Papers
 web app site, but that's not relevant to the issue here.  If I ever get off
 my lazy butt and write some patches to their code for the site to fix this
 sort of thing (which is why I'd created a fork in the first place), then
 I'd be able to get at my account w/o needing them to do something.

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

Re: [Talk-de] Veröffentlichung OpenTopoMap Garmin-Edition

2014-08-28 Thread Sven Geggus

fly lowfligh...@googlemail.com wrote:

 FIXME könnte vielleicht durch notes ersetzt werden.

Das bringts ja sowieso nur wenn die Daten sehr aktuell sind.

Sven

-- 
Das Einzige wovor wir Angst haben müssen ist die Angst selbst
(Franklin D. Roosevelt)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Anfänger: Hausnummern als eigener Node oder ans Gebäude?

2014-08-28 Thread Andreas Goss


Wo trage ich z.B. die contact:*


Dürfte ich mal fragen wie du auf contact: gekommen bist? Ist nämlich 
nicht grade die gängigste Tagging Variante.

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [Talk-de] Wanderweg splittet sich in zwei Alternativen

2014-08-28 Thread k4r573n

On 21.08.2014 19:26, hike39 wrote:

 Am 21.08.2014 um 19:07 schrieb Hartmut Holzgraefe:
 Für die komplette Diskussion der Alternativen siehe


 http://wiki.openstreetmap.org/wiki/Relation:route#Multiple_routes_share_the_same_path

für mich war auch noch dieses Proposal hilfreich
http://wiki.openstreetmap.org/wiki/Proposed_features/Route_Segments

Gruß
Karsten


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

Re: [Talk-it] regione toscana

2014-08-28 Thread cesare gerbino

Mi unisco ai compliementi, davvero un ottima iniziativa. Ora speriamo che
diventi presto una sorta di best practise presso altre P.A.

 Grazie!

 Cesare

Cesare Gerbino

http://cesaregerbino.wordpress.com/
http://www.facebook.com/cesare.gerbino
http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl
https://twitter.com/CesareGerbino
http://www.linkedin.com/pub/cesare-gerbino/56/494/77b



Il giorno 27 agosto 2014 18:56, Simone Cortesi sim...@cortesi.com ha
scritto:

 Ciao,
 Regione Toscana ha controfirmato con Wikimedia Italia (OpenStreetMap
 Italia) la convenzione relativa alle basi dati geografiche.

 Qui il testo:


 http://www301.regione.toscana.it/bancadati/atti/DettaglioAttiD.xml?codprat=2014AD0004611


 --
 -S

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

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

Re: [Talk-it] Digest di Talk-it, Volume 93, Numero 36

2014-08-28 Thread franco selva

lo so che ci sono dei tratti contesi, però tutti i confini, anche quelli
con la tanzania e con il congo sono stati grossolanamente delineati
seguendo in qualche maniera il letto dei fiumi (tutto a vantaggio del
burundi tra l'altro). idem per i confini interni tra le varie province.
grazie comunque della considerazione
franco

[image: Foto]


Il giorno 27 agosto 2014 11:54, talk-it-requ...@openstreetmap.org ha
scritto:

 Invia le richieste di iscrizione alla lista Talk-it all'indirizzo
 talk-it@openstreetmap.org

 Per iscriverti o cancellarti attraverso il web, visita
 https://lists.openstreetmap.org/listinfo/talk-it
 oppure, via email, manda un messaggio con oggetto `help' all'indirizzo
 talk-it-requ...@openstreetmap.org

 Puoi contattare la persona che gestisce la lista all'indirizzo
 talk-it-ow...@openstreetmap.org

 Se rispondi a questo messaggio, per favore edita la linea dell'oggetto
 in modo che sia più utile di un semplice Re: Contenuti del digest
 della lista Talk-it...


 Argomenti del Giorno:

1. Re: Carta tecnica Comune di Lecce (Francesco Piero Paolicelli)
2. Re: Carta tecnica Comune di Lecce (Francesco Piero Paolicelli)
3. Confini Burundi (franco selva)
4. Re: Confini Burundi (Ilario Valdelli)


 --

 Message: 1
 Date: Wed, 27 Aug 2014 11:08:23 +0200
 From: Francesco Piero Paolicelli pierso...@gmail.com
 To: openstreetmap list - italiano talk-it@openstreetmap.org
 Subject: Re: [Talk-it] Carta tecnica Comune di Lecce
 Message-ID: eb7b71d2-c169-4fa0-b12e-5a4e97ace...@gmail.com
 Content-Type: text/plain; charset=utf-8

 Su Lecce, appena finiranno il nuovo piano regolatore generale, potró
 pubblicare la mappa aggiornata del tessuto urbano.
 Alla regione non ci sono ancora arrivato

 Inviato da iPhone

  Il giorno 27/ago/2014, alle ore 10:14, Federico Cortese 
 cortese...@gmail.com ha scritto:
 
  2014-08-26 22:34 GMT+02:00 Simone Cortesi sim...@cortesi.com:
  I miei primi contatti risalgono al 2009, in ottica di importazione
  OSM, ma non si è mai riusciti ad andare oltre un certo punto.
 
  E questo è un peccato, perche' i dati no mi pare siano stati poi
  aggiornati da allora, e rischiano, oggi, di essere vecchi.
  Hai perfettamente ragione, mi pare che i dati della CTR Puglia risalgano
 al 2006, all'epoca erano all'avanguardia, oggi cominciano a diventare
 vecchiotti, oltre a mostrare numerosissime imprecisioni come venuto fuori
 durante l'import dei fabbricati per Lecce. Tuttavia in linea di massima si
 tratta comunque di materiale utilissimo a formare una buona base
 cartografica. Oltre ai fabbricati ci sarebbe tanto da importare (dai dati
 relativi all'uso del suolo, alle cavità naturali, a tanto e tanto altro).
 Tra l'altro sul sito del SIT Puglia è stato da un po' di tempo tolto
 l'obbligo di essere registrati per scaricare alcuni dati (tipo i vettoriali
 della CTR) ed è stata aggiunta la rassicurante dicitura Puglia.con: La
 condivisione della conoscenza per il governo del territorio, ma credo che
 bisognerebbe chiarire loro cosa significhi condivisione! Speriamo che i
 tuoi contatti possano portare buoni risultati!
 
  2014-08-27 9:24 GMT+02:00 Maurizio Napolitano napoo...@gmail.com:
  - dati ricalcati da TuttoCittà
 
  se l'import ha lavorato sopra questi dati e, all'origine violano
 licenza, allora da lì a tutte le modifiche va via tutto
  Se sostituiscono è ok ma suppongo che ci saranno alcuni attributi
 assenti nella CRT
 
  Non so se i dati dell'import Arch. Biallo del 2009 siano stati ricalcati
 da Tuttocittà e mi sembrerebbe strano, tuttavia le strade sono state tutte
 riviste e corrette (se non spesso ridisegnate da zero) manualmente mediante
 le foto Bing, Realvista o PCN; quando si è intervenuti sono stati rimossi i
 tag source e attribution di cui si è parlato in precedenza. L'import ha
 riguardato solo i fabbricati.
  - comunità
  solitamente gli import aiutano la mappa ma non aiutano a creare comunità
  Il consiglio ora è di proporre delle attività di miglioramento dei dati
 aggiungendo sensi unici, tariffe parcheggi, numeri civici, vecchia
 toponomastica, toponomastica locale, accessibilità disabili motori, ...
 dettagli vari ...
  Oltre che di riuso di applicazioni basate su OSM (vedere la mappa usate
 dall'editoria del comune sarebbe molto col)
  Immagino che su questo abbiate già qualcosa in cantiere per le attività
 della candidatura di Lecce2019
  Condivido a pieno: l'import serve solo ad avere una buona base per poter
 procedere alla puntuale mappatura del territorio, che secondo me diventa
 molto più semplice se la cartografia è completa di fabbricati. Anche solo
 inserire i numeri civici viene notevolmente facilitato. Si tratta quindi
 solo di un punto di partenza per gli auspicabili risultati che hai indicato!
 
  Ciao
 
  Federico
  ___
  Talk-it mailing list
  Talk-it@openstreetmap.org

Re: [Talk-it] [wikimedia-it] regione toscana

2014-08-28 Thread Fabrizio Carrai

Mi associo!

--
FabC


Il giorno 27 agosto 2014 19:39, Luca Corsato luc...@gmail.com ha scritto:

 Congratulazioni!

 luca corsato
 +393339187853
 fb luca.corsato
 tw lucacorsato
 www.lucacorsato.it

  On 27 Aug 2014, at 18:56, Simone Cortesi sim...@cortesi.com wrote:
 
  Ciao,
  Regione Toscana ha controfirmato con Wikimedia Italia (OpenStreetMap
  Italia) la convenzione relativa alle basi dati geografiche.
 
  Qui il testo:
 
 
 http://www301.regione.toscana.it/bancadati/atti/DettaglioAttiD.xml?codprat=2014AD0004611
 
 
  --
  -S
  ___
  Mailing list dell'associazione Wikimedia Italia
  Invio messaggi in lista: associazi...@wikimedia.it
  Configurazione utente: http://mailman.wikimedia.it/listinfo/associazione

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




-- 
*Fabrizio*
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-gb-westmidlands] September mapping party

2014-08-28 Thread Andy Robinson

Senior moment ;-)

From: Rob Nickerson [mailto:rob.j.nicker...@gmail.com] 
Sent: 28 August 2014 00:23
To: Andy Robinson
Cc: Matthijs Melissen; talk-gb-westmidlands
Subject: Re: [Talk-gb-westmidlands] September mapping party

Don't you mean NW? If so then I'll go do that new housing development we talked 
about on the list a few weeks back.

Matthijs, there is a lot to do in terms of shops. If you're coming in by train 
then you should be able to skip Warwick Row (mainly estate agents) as I did 
these last year. I'm hoping most will be the same as estate agents move less 
frequently.

Rob

On 27 Aug 2014 16:36, Andy Robinson ajrli...@gmail.com wrote:

I'll be cycling over from Sutton Coldfield if the weather holds and will map 
somewhere along the logical alignment  coming in (northeast quadrant).

Cheers
Andy

-Original Message-
From: Matthijs Melissen [mailto:i...@matthijsmelissen.nl]
Sent: 27 August 2014 16:07
To: talk-gb-westmidlands
Subject: Re: [Talk-gb-westmidlands] September mapping party

Hi all,

I will be focussing on retail and pubs/restaurants within the ring road, 
including the shopping malls

See you tomorrow!

-- Matthijs

On 23 August 2014 11:06, Rob Nickerson rob.j.nicker...@gmail.com wrote:
 Hi All,

 If mapping in Coventry city centre can you please use the Warwickshire
 aerial imagery for aligning things (I'm mid way through better
 building mapping in the city centre). Lots and lots of shops to map
 and some out of town centre new developments that will need a survey.
 I'll have my car if anyone wants a lift.

 We struggle with pubs in Coventry. I suggest we try the Aardvark this time.
 It's cheap food (but pricey beer) and close to the train station:

 http://www.openstreetmap.org/way/161441499

 Rob

 On 22 August 2014 16:26, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Yeah I was thinking the same when I drove to work this morning.
 Shouldnt make a habit of it though :-p

 I'll put a tweet out.

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

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

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4745 / Virus Database: 4015/8113 - Release Date: 08/28/14

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

Re: [Talk-se] Kommunal kartdata i OSM?

2014-08-28 Thread Erik Johansson

2014-08-27 13:07 GMT+02:00 Christoffer Holmstedt
christoffer.holmst...@gmail.com:
 psidata-länken hos Trollhättan ger 404 fel, är det bara jag?

Ah jo, skulle ha varit mer tydlig med att anledningen till att
Trollhättan ännu inte är med på e-delegationens PSI datakoll eftersom
de inte har någon /psidata på sin hemsida. Så 404 var det jag tyckte
de kunde undvika.

Eftersom få kommuner listar geodata på sina PSIdata sidor så skulle
Trollhättan placera sig högt upp om listan vore rankad.

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

Re: [Talk-es] Catastro Valencia

2014-08-28 Thread Moises Arcos

Buenos días,

en el caso de Sevilla, había un responsable para la cuenta, pero no
llegábamos a contactar con él, así que PerroVerd nos asignó la cuenta de
Catastro Sevilla para poder empezar a editar.

Con respecto a la página, nosotros lo que hemos hecho es usar la página de
Sevilla que ya estaba creada y mediante un script de Ale Díaz hemos ido
creando las páginas de cada uno de los municipios de la provincia, de
manera que tengamos la portada para cada uno de ellos y todo aquél que
quiera participar se encuentre al menos algo ya iniciado.

Es una de las líneas de trabajo que tenemos en Geoinquietos Sevilla, la
importación catastral de todos los municipios de la provincia.

Saludos!!!


El 27 de agosto de 2014, 22:03, Matías Taborda Barroso 
taborda.barr...@gmail.com escribió:

 Hola.

 En teoria, siguiendo las indicaciones de la wiki[1], debería pasarte las
 credenciales PerroVerd [2]

 [1] http://wiki.openstreetmap.org/wiki/Spanish_Cadastre/results

 [2] http://wiki.openstreetmap.org/wiki/User:PerroVerd

 Salud y buena suerte.



 El 27 de agosto de 2014, 20:15, Jorge Sanz js...@osgeo.org escribió:

 Buenas,

 Me gustaría probar a importar datos de catastro en la provincia de
 Valencia y no hay cuenta creada. ¿Quién me atiende? :-)

 Otra cosa veo que hay creada una página por provincia con un listado
 de municipios, ¿hay algún mecanismo fácil para generar esa lista en el
 wiki o la creo y meto el municipio con el que voy a empezar a currar y
 carril?

 Saludos

 --
 Jorge Sanz
 http://www.osgeo.org
 http://wiki.osgeo.org/wiki/Jorge_Sanz

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



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


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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Simó Albert i Beltran

Como se ha comentado hay certos valores que se consideran asumidos por
defecto, en esta lista solo podemos dar nuestras opiniones y hablar de
lo establecido. Creo que entre todos podemos mejorar, te animo ha hacer
una propuesta de cambio oficial.

De todos modos, si quieres revisar los datos, mejor si consultas los
datos directamente, en vez de los datos tratados. Por ejemplo puedes
usar la siguiente consulta para ver las calles sin valor en la etiqueta
oneway.

http://overpass-turbo.eu/s/4Lb 


pgpBUK6MkKcAP.pgp
Description: PGP signature
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] doble sentido de las calles

2014-08-28 8:44 GMT+02:00 Simó Albert i Beltran s...@probeta.net:

 Como se ha comentado hay certos valores que se consideran asumidos por
 defecto, en esta lista solo podemos dar nuestras opiniones y hablar de
 lo establecido. Creo que entre todos podemos mejorar, te animo ha hacer
 una propuesta de cambio oficial.

 De todos modos, si quieres revisar los datos, mejor si consultas los
 datos directamente, en vez de los datos tratados. Por ejemplo puedes
 usar la siguiente consulta para ver las calles sin valor en la etiqueta
 oneway.

 http://overpass-turbo.eu/s/4Lb

Esto era lo que necesitaba para contribuir :).

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Jose Luis Perez Diez

El Wednesday 27 August 2014 20:05:01 Jorge Sanz Sanfructuoso va escriure:
 surface tiene unpaved, paved, asphalt, 
 Me hecho las manos a la cabeza ala.. pero que no pone si esta asfaltada
 ahora que hago puedo pasar por esa calle no no puedo. Pues no. Pues esto es
 lo mismo.

Si entiendo lo que dices y creo que un render o un analizador del grafo según 
este diseñado puede optar por crear un valor por defecto para los atributos no 
comunicados. Un editor no ha crear tuplas (key,value) y grabarlas en la base de 
datos usando estos criterios.

 
 Y como lo acaba de explicar Antonio creo que es el mejor ejemplo que
 se podía dar. ¿Que haces en la vida real?
 
 Creo que yo y mas gente te hemos dado varios ejemplos de todo pero no vas a
 salir de tu idea. Si quieres puedes hacer una propuesta en la wiki para
 cambiarlo como se hace con otras etiquetas, mas no te puedo hacer. Los
 mapas de OSM cada vez se usan mas y si hubiera un problema tan grande con
 esta lógica en una cosa tan básica como la dirección de las calles no creo
 que se usaran cada vez mas.

Según la wiki 
oneway solo tiene 3 valores posibles y un uso muy concreto

yes se usa cuando el defecto para ese tipo de way es de dos sentidos de 
circulación (valido para la mayoría de valores highway)

no uso:
1. cuando el defecto es sentido unico highway = motorway_link.
2. cuando la mayoría de las ways de la zona son 
oneway=yes

-1indica que es oneway y el orden de los nodos esta invertido
uso cuando es complicado o imposible cambiar el orden de los nodos

http://3.bp.blogspot.com/_ovJS1Em-6dg/RsQKDNgIqfI/MsU/oQ8_WtbPHKI/s1600-h/roundAbout.jpg
o en una relación o una vía que sea una linea de costa

Según mi punto de vista, el problema existe en parte debe estar en la 
documentación del editor que esta usando Xavier (supongo que es iD) que 
cuando no esta notificada alguna key importante  muestra  el valores por 
defecto de esa para ese tipo de vía con la coletilla assumed traducida al 
idioma del navegador. Ademas puesto que la mayoría de ways/changesets no tienen 
puesta la source , si no hay alguna indicación en el titulo del changeset, no 
se puede saber si no se notifico el valor por desconocimiento, por que no es 
necesario. 

por ejemplo en https://www.openstreetmap.org/way/35481972/history el oneway=yes 
es redundante e innecesario ya que no hay niguna motorway_link en la zona con 
algun tramo que sea oneway=no

Espero no haberlo liado mas,

jluis 






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

Re: [Talk-es] doble sentido de las calles

La query con v= no da los nodos sin el atributo (o cuyo atributo no
tiene valor). Me parece que devuelve los nodos que tienen algun valor
(cualquiera) en ese atributo.

No he visto una manera en la referencia del lenguaje de queries de
decir sencillamente que no tenga tal atributo.

Para el caso que nos ocupa, como los posibles valores son dos he
podido hacer la consulta con

has-kv k=oneway modv=not regv=yes|no/

podeis ver el resultado en

http://overpass-turbo.eu/s/4Lj

Sabeis si hay una manera mas idiomatica de preguntar eso a esa API?
Las zonas amarillas por que salen con esta query?

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Luis García Castro

El 28 de agosto de 2014, 11:16, Jose Luis Perez Diez 
jl...@escomposlinux.org escribió:

 por ejemplo en https://www.openstreetmap.org/way/35481972/history el
 oneway=yes es redundante e innecesario ya que no hay niguna motorway_link
 en la zona con algun tramo que sea oneway=no


No veo que sea un buen ejemplo. Si no añades restricciones de giro esa vía
necesita sí o sí el oneway=yes :-\


-- 

Luis García
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] doble sentido de las calles

Hombre jluis, tu por aqui :).

La wiki dice:

oneway=no is used to confirm that (a part of) a street is NOT a
oneway street. (Use only in order to avoid mapping errors in areas
where e.g. oneway streets are common, or to override defaults.)

Las poblaciones en mi experiencia son areas donde las lineal ways
son en general de un solo sentido, y las de doble sentido
excepcionales.

Mi conclusion es que la wiki misma nos dice que hay que poner no, no
dejarlo sin valor.

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Jo

continua de leerlo hasta la conclusion se vuelve en ausencia del tag oneway
significa que el way es de doble sentido.

Jo


2014-08-28 11:26 GMT+02:00 Xavier Noria f...@hashref.com:

 Hombre jluis, tu por aqui :).

 La wiki dice:

 oneway=no is used to confirm that (a part of) a street is NOT a
 oneway street. (Use only in order to avoid mapping errors in areas
 where e.g. oneway streets are common, or to override defaults.)

 Las poblaciones en mi experiencia son areas donde las lineal ways
 son en general de un solo sentido, y las de doble sentido
 excepcionales.

 Mi conclusion es que la wiki misma nos dice que hay que poner no, no
 dejarlo sin valor.

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

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread María Arias de Reyna

Hola,

Independientemente de que leyendo este tema creo que os estáis perdiendo en
los detalles, me meto:


On Thu, Aug 28, 2014 at 11:26 AM, Xavier Noria f...@hashref.com wrote:

 Hombre jluis, tu por aqui :).

 La wiki dice:

 oneway=no is used to confirm that (a part of) a street is NOT a
 oneway street. (Use only in order to avoid mapping errors in areas
 where e.g. oneway streets are common, or to override defaults.)



O sea, oneway=no se usa para CONFIRMAR que

Es decir, es algo que se supone, pero que si quieres confirmarlo, pues lo
pones. Pero si no lo pones, se supone que oneway cuando no está, es que no.



 Las poblaciones en mi experiencia son areas donde las lineal ways
 son en general de un solo sentido, y las de doble sentido
 excepcionales.



En cambio en mi experiencia las calles suelen ser de doble sentido salvo en
casos muy concretos.

Pero nuestras experiencias dan igual. Lo importante es que en las
directrices de OSM dice que oneway=no sirve para confirmar, pero que no
es obligatorio.



 Mi conclusion es que la wiki misma nos dice que hay que poner no, no
 dejarlo sin valor.


Mi conclusión es por tanto justo la contraria :)

Aunque tengo que reconocer que yo siempre lo pongo, igual que pongo el
asphalted y todo lo demás que sepa rellenar. Cosas de haber trabajado con
algoritmos de rutas y echar en falta giros prohibidos, limitaciones de
velocidad, pesos y alturas máximas, etc...
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Jaime Crespo

Como bién dice Simó, esto no es algo que se pueda decidir en esta lista,
porque no es algo que concierna a la comunidad hispanoablante y/o española.
Te invito a acercarlo a la lista de discusión internacional, 
https://lists.openstreetmap.org/listinfo/talk o específicamente a 
https://lists.openstreetmap.org/listinfo/tagging.

Aunque aquí se decidiera que oneway debería ser igual a 3.1416, no tendría
ninguna oficialidad (nótense las comillas).

-- 
Jaime Crespo
http://dbahire.com
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] doble sentido de las calles

2014-08-28 11:51 GMT+02:00 María Arias de Reyna dela...@gmail.com:

 Hola,

 Independientemente de que leyendo este tema creo que os estáis perdiendo en
 los detalles, me meto:


 On Thu, Aug 28, 2014 at 11:26 AM, Xavier Noria f...@hashref.com wrote:

 Hombre jluis, tu por aqui :).

 La wiki dice:

 oneway=no is used to confirm that (a part of) a street is NOT a
 oneway street. (Use only in order to avoid mapping errors in areas
 where e.g. oneway streets are common, or to override defaults.)



 O sea, oneway=no se usa para CONFIRMAR que

 Es decir, es algo que se supone, pero que si quieres confirmarlo, pues lo
 pones. Pero si no lo pones, se supone que oneway cuando no está, es que no.

Pero dice que se use en zonas donde las calles de un solo sentido son
la norma, como Barcelona.

Si el valor no y no tener valor fueran equivalentes, entonces no
haria falta valor no. No se pone nada en ninguna de las de doble
sentido y estas dejando la misma informacion.

Pero hay valor no. Algo hay que no cuadra.

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 12:32 GMT+02:00 Jaime Crespo jy...@jynus.com:

 Como bién dice Simó, esto no es algo que se pueda decidir en esta lista,
 porque no es algo que concierna a la comunidad hispanoablante y/o española.
 Te invito a acercarlo a la lista de discusión internacional,
 https://lists.openstreetmap.org/listinfo/talk o específicamente a
 https://lists.openstreetmap.org/listinfo/tagging.

 Aunque aquí se decidiera que oneway debería ser igual a 3.1416, no tendría
 ninguna oficialidad (nótense las comillas).

Gracias Jaime,

Si, voy a escribir a esas listas. Entiendo la convencion que
explicais, pero no entiendo su logica, y eso hay que hablarlo en una
lista de desarrollo de OSM o algo asi que es donde se decide el diseño
de datos.

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

Re: [Talk-es] doble sentido de las calles

Si, yo tampoco lo he visto.

On Thu, Aug 28, 2014 at 12:59 PM, Jose Luis Perez Diez
jl...@escomposlinux.org wrote:
 El Thursday 28 August 2014 11:42:17 Jo va escriure:
 continua de leerlo hasta la conclusion se vuelve en ausencia del tag oneway
 significa que el way es de doble sentido.

 yo no lo veo en la pagina lo unico que veo es:

 Implied oneway restriction
 Some tags (such as junction=roundabout, highway=motorway and others) imply 
 oneway=yes and therefore the oneway tag is optional. If a tag implies a 
 oneway value this is noted on the implying tag's wiki page.

 y mas abajo un enlace a lo que para iD el defecto es de sentido unico
 https://github.com/bhousel/iD/blob/master/js/id/core/oneway_tags.js



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

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Jose Luis Perez Diez

El Thursday 28 August 2014 11:21:03 Luis García Castro va escriure:
 No veo que sea un buen ejemplo. Si no añades restricciones de giro esa vía
 necesita sí o sí el oneway=yes :-\
 
las highway=motorway_link son oneway=yes por defecto.


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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Antonio Navarro

Bueno,

Supongo que cada uno lee lo que quiere ;-D

oneway = no

*oneway*=no is used to confirm that (a part of) a street is NOT a oneway
street. (Use only in order to avoid mapping errors in areas where e.g.
oneway streets are common, or to override defaults.)


Lo del 'Use only...' creo que lo aclara lo suficiente.

De todas formas, no veo dónde está el problema. Si quieres poner el
'oneway=no' y que por lo que dices en la zona donde mapeas evitaría
confusiones, pues adelante.

Si lo que buscas es una etiqueta de 'esto lo he puesto a conciencia y está
correcto', olvídate porque creo que ni existe ni serviría de nada porque
'El Mundo Real'(tm) cambia y la API para que informe los cambios a
OpenStreetMap todavía no está hecha ;-D


Un saludo,

-- 
Antonio Navarro

mailto:anto...@hunos.net
mailto:antonio.navarro...@gmail.com



2014-08-28 13:00 GMT+02:00 Xavier Noria f...@hashref.com:

 Si, yo tampoco lo he visto.

 On Thu, Aug 28, 2014 at 12:59 PM, Jose Luis Perez Diez
 jl...@escomposlinux.org wrote:
  El Thursday 28 August 2014 11:42:17 Jo va escriure:
  continua de leerlo hasta la conclusion se vuelve en ausencia del tag
 oneway
  significa que el way es de doble sentido.
 
  yo no lo veo en la pagina lo unico que veo es:
 
  Implied oneway restriction
  Some tags (such as junction=roundabout, highway=motorway and others)
 imply oneway=yes and therefore the oneway tag is optional. If a tag implies
 a oneway value this is noted on the implying tag's wiki page.
 
  y mas abajo un enlace a lo que para iD el defecto es de sentido unico
  https://github.com/bhousel/iD/blob/master/js/id/core/oneway_tags.js
 
 
 
  ___
  Talk-es mailing list
  Talk-es@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-es

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

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Luis García Castro

El 28 de agosto de 2014, 13:10, Jose Luis Perez Diez 
jl...@escomposlinux.org escribió:

 las highway=motorway_link son oneway=yes por defecto.


Ah, claro. Tienes razón :-)


-- 

Luis García
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Luis García Castro

El 28 de agosto de 2014, 13:14, Luis García Castro lui...@gmail.com
escribió:


 El 28 de agosto de 2014, 13:10, Jose Luis Perez Diez 
 jl...@escomposlinux.org escribió:

 las highway=motorway_link son oneway=yes por defecto.


 Ah, claro. Tienes razón :-)


Aunque estamos en las mismas, en cierto modo es redundante pero la etiqueta
no sobra. De la propia wiki:

Tagging oneway[edit
http://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dmotorway_linkaction=editsection=2
]

Most motorway_link roads will be one way, and should be tagged oneway
http://wiki.openstreetmap.org/wiki/Key:oneway=yes
http://wiki.openstreetmap.org/wiki/Tag:oneway%3Dyes. Any unusual motorway
link road which is two-way should be explicitly tagged oneway
http://wiki.openstreetmap.org/wiki/Key:oneway=no
http://wiki.openstreetmap.org/wiki/Tag:oneway%3Dno. Note that this is
different to the way we treat other highway classifications, because
motorway link roads are so often one way. Explicit tagging (either way) can
be important, since *some* tools interpret motorway link roads as
implicitly oneway=yes unless tagged oneway=no.



-- 

Luis García
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] doble sentido de las calles

On Thu, Aug 28, 2014 at 1:12 PM, Antonio Navarro anto...@hunos.net wrote:

 Si lo que buscas es una etiqueta de 'esto lo he puesto a conciencia y está
 correcto', olvídate porque creo que ni existe ni serviría de nada porque 'El
 Mundo Real'(tm) cambia y la API para que informe los cambios a OpenStreetMap
 todavía no está hecha ;-D

Cuando tu pones el nombre de una calle, tu intencion no es decir esto
esta puesto a conciencia y esta correcto por los siglos de los
siglos. Obviamente te has podido equivocar, o puede cambiar.

Ponerle nombre a una calle no es mas que ponerle el nombre con todo lo
de vida real que eso supone.

Bien, pues poner no o yes al sentido de una calle es lo mismo, puede haber
errores, puede cambiar, pero en la misma medida que lo puede hacer
otro atributo.

Que no tengas el 100% de certeza de que el valor es correcto en un
momento dado no quiere decir que entrar el valor no tenga
sentido. Naturalmente que tiene sentido, por eso entramos los valores!

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

Re: [Talk-es] doble sentido de las calles

Hago un resumen del thread, que llevamos cienes de mensajes :):

1. El valor por defecto de oneway depende del tipo de via. Para calles
es no (implicito).

2. En una ciudad como Barcelona donde la mayoria de calles son de un
solo sentido, el wiki recomienda poner no explicitamente.

3. Para poder saber que calles no tienen oneway puesto en una cierta
area se puede usar http://overpass-turbo.eu/s/4Lx (si doy con una
query mas idiomatica la envio).

Mi interpretacion:

A posteriori, supongo que los implicitos en (1) estan definidos de
acuerdo a una vision global del mundo, o una vision americana, o algo
asi. Es un compromiso, escoges un valor, a sabiendas de que no sera un
valor por defecto adecuado/util en ciertos lugares (como Barcelona).

Todo cuadra para mi si dado (1), se entiende que la practica normal
para Madrid seria (2), en lugar de no marcar las cosas. Porque la
confirmacion en Madrid aporta informacion y es por ello que la wiki lo
recomienda. Es lo logico para mi. Mientras que a lo mejor en Chicago
downtown no hace falta.

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Antonio Navarro

Es que no pones 'yes o no' al 'sentido de una calle' (que los valores
serían 'left, right, both' o algo similar), lo pones a 'dirección única' y
en una carretera sin señalizar, vuelvo a repetir, en general (no me conozco
la legislación de todos los países del planeta), es de doble dirección y lo
que se suele indicar es la prohibición cuando eso no es así.

Esto no es comparable con 'el nombre de una calle', porque la ausencia de
nombre no implica uno 'por defecto'. Imagina que hay una zona donde les da
por techar las carreteras, con sombrita para el verano y paneles solares,
por ejemplo. Y añaden una etiqueta que indica si la carretera está
'techada'. ¿Hay que ponerle a todas las vías el 'techado=no'? No le veo
sentido cuando la mayoría son 'sin techar'. Tendría sentido quizá en esa
zona si sólo unas pocas están sin techo. O cuando la 'moda' de techar con
paneles solares se extienda y se generalice por todas partes, pero hasta
entonces es una redundancia que no aporta nada o sólo aporta en
determinadas condiciones (básicamente que la 'realidad'(tm)  de esa zona
sea la contraria al 'valor por defecto').

Un saludo,

-- 
Antonio Navarro

mailto:anto...@hunos.net
mailto:antonio.navarro...@gmail.com



El 28 de agosto de 2014, 13:22, Xavier Noria f...@hashref.com escribió:

 On Thu, Aug 28, 2014 at 1:12 PM, Antonio Navarro anto...@hunos.net
 wrote:

  Si lo que buscas es una etiqueta de 'esto lo he puesto a conciencia y
 está
  correcto', olvídate porque creo que ni existe ni serviría de nada porque
 'El
  Mundo Real'(tm) cambia y la API para que informe los cambios a
 OpenStreetMap
  todavía no está hecha ;-D

 Cuando tu pones el nombre de una calle, tu intencion no es decir esto
 esta puesto a conciencia y esta correcto por los siglos de los
 siglos. Obviamente te has podido equivocar, o puede cambiar.

 Ponerle nombre a una calle no es mas que ponerle el nombre con todo lo
 de vida real que eso supone.

 Bien, pues poner no o yes al sentido de una calle es lo mismo, puede
 haber
 errores, puede cambiar, pero en la misma medida que lo puede hacer
 otro atributo.

 Que no tengas el 100% de certeza de que el valor es correcto en un
 momento dado no quiere decir que entrar el valor no tenga
 sentido. Naturalmente que tiene sentido, por eso entramos los valores!

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

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

Re: [Talk-es] doble sentido de las calles

Fijate en el parrafo al que estaba respondiendo.

El comentario era: si quieres etiquetar para decir que es correcto
olvidate porque hay errores y las cosas cambian. Los datos tienen
errores y cambian si, pero eso aplica a cualquier atributo, y no por
ello dejamos de etiquetar.


2014-08-28 13:57 GMT+02:00 Antonio Navarro anto...@hunos.net:
 Es que no pones 'yes o no' al 'sentido de una calle' (que los valores serían
 'left, right, both' o algo similar), lo pones a 'dirección única' y en una
 carretera sin señalizar, vuelvo a repetir, en general (no me conozco la
 legislación de todos los países del planeta), es de doble dirección y lo que
 se suele indicar es la prohibición cuando eso no es así.

 Esto no es comparable con 'el nombre de una calle', porque la ausencia de
 nombre no implica uno 'por defecto'. Imagina que hay una zona donde les da
 por techar las carreteras, con sombrita para el verano y paneles solares,
 por ejemplo. Y añaden una etiqueta que indica si la carretera está
 'techada'. ¿Hay que ponerle a todas las vías el 'techado=no'? No le veo
 sentido cuando la mayoría son 'sin techar'. Tendría sentido quizá en esa
 zona si sólo unas pocas están sin techo. O cuando la 'moda' de techar con
 paneles solares se extienda y se generalice por todas partes, pero hasta
 entonces es una redundancia que no aporta nada o sólo aporta en determinadas
 condiciones (básicamente que la 'realidad'(tm)  de esa zona sea la contraria
 al 'valor por defecto').

 Un saludo,

 --
 Antonio Navarro
 
 mailto:anto...@hunos.net
 mailto:antonio.navarro...@gmail.com
 


 El 28 de agosto de 2014, 13:22, Xavier Noria f...@hashref.com escribió:

 On Thu, Aug 28, 2014 at 1:12 PM, Antonio Navarro anto...@hunos.net
 wrote:

  Si lo que buscas es una etiqueta de 'esto lo he puesto a conciencia y
  está
  correcto', olvídate porque creo que ni existe ni serviría de nada porque
  'El
  Mundo Real'(tm) cambia y la API para que informe los cambios a
  OpenStreetMap
  todavía no está hecha ;-D

 Cuando tu pones el nombre de una calle, tu intencion no es decir esto
 esta puesto a conciencia y esta correcto por los siglos de los
 siglos. Obviamente te has podido equivocar, o puede cambiar.

 Ponerle nombre a una calle no es mas que ponerle el nombre con todo lo
 de vida real que eso supone.

 Bien, pues poner no o yes al sentido de una calle es lo mismo, puede
 haber
 errores, puede cambiar, pero en la misma medida que lo puede hacer
 otro atributo.

 Que no tengas el 100% de certeza de que el valor es correcto en un
 momento dado no quiere decir que entrar el valor no tenga
 sentido. Naturalmente que tiene sentido, por eso entramos los valores!

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



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


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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Antonio Navarro

Si falta la etiqueta 'name' en una calle, es que no se ha etiquetado. Si
falta la etiqueta 'oneway' no puedes deducir lo mismo porque sólo se indica
donde es necesaria (tanto a 'yes' como a 'no' donde se requiera). Entiendo
que pueda causar incertidumbre si no está, pero no más que cualquier otra
etiqueta. Es como si en el mapa ves una calle que no tiene farolas. ¿No las
tiene realmente o no se han etiquetado? ¿Añadimos nodos que digan 'sin
farola' por todas partes para eliminar incertidumbre?

Debe ser problema de que me cuesta etiquetar cosas 'en negativo', no hay
restricción de giro, no hay arboles, no hay restricción de sentido, no
hay no terminamos nunca :-D

-- 
Antonio Navarro

mailto:anto...@hunos.net
mailto:antonio.navarro...@gmail.com



El 28 de agosto de 2014, 14:04, Xavier Noria f...@hashref.com escribió:

 Fijate en el parrafo al que estaba respondiendo.

 El comentario era: si quieres etiquetar para decir que es correcto
 olvidate porque hay errores y las cosas cambian. Los datos tienen
 errores y cambian si, pero eso aplica a cualquier atributo, y no por
 ello dejamos de etiquetar.


 2014-08-28 13:57 GMT+02:00 Antonio Navarro anto...@hunos.net:
  Es que no pones 'yes o no' al 'sentido de una calle' (que los valores
 serían
  'left, right, both' o algo similar), lo pones a 'dirección única' y en
 una
  carretera sin señalizar, vuelvo a repetir, en general (no me conozco la
  legislación de todos los países del planeta), es de doble dirección y lo
 que
  se suele indicar es la prohibición cuando eso no es así.
 
  Esto no es comparable con 'el nombre de una calle', porque la ausencia de
  nombre no implica uno 'por defecto'. Imagina que hay una zona donde les
 da
  por techar las carreteras, con sombrita para el verano y paneles solares,
  por ejemplo. Y añaden una etiqueta que indica si la carretera está
  'techada'. ¿Hay que ponerle a todas las vías el 'techado=no'? No le veo
  sentido cuando la mayoría son 'sin techar'. Tendría sentido quizá en esa
  zona si sólo unas pocas están sin techo. O cuando la 'moda' de techar con
  paneles solares se extienda y se generalice por todas partes, pero hasta
  entonces es una redundancia que no aporta nada o sólo aporta en
 determinadas
  condiciones (básicamente que la 'realidad'(tm)  de esa zona sea la
 contraria
  al 'valor por defecto').
 
  Un saludo,
 
  --
  Antonio Navarro
  
  mailto:anto...@hunos.net
  mailto:antonio.navarro...@gmail.com
  
 
 
  El 28 de agosto de 2014, 13:22, Xavier Noria f...@hashref.com escribió:
 
  On Thu, Aug 28, 2014 at 1:12 PM, Antonio Navarro anto...@hunos.net
  wrote:
 
   Si lo que buscas es una etiqueta de 'esto lo he puesto a conciencia y
   está
   correcto', olvídate porque creo que ni existe ni serviría de nada
 porque
   'El
   Mundo Real'(tm) cambia y la API para que informe los cambios a
   OpenStreetMap
   todavía no está hecha ;-D
 
  Cuando tu pones el nombre de una calle, tu intencion no es decir esto
  esta puesto a conciencia y esta correcto por los siglos de los
  siglos. Obviamente te has podido equivocar, o puede cambiar.
 
  Ponerle nombre a una calle no es mas que ponerle el nombre con todo lo
  de vida real que eso supone.
 
  Bien, pues poner no o yes al sentido de una calle es lo mismo, puede
  haber
  errores, puede cambiar, pero en la misma medida que lo puede hacer
  otro atributo.
 
  Que no tengas el 100% de certeza de que el valor es correcto en un
  momento dado no quiere decir que entrar el valor no tenga
  sentido. Naturalmente que tiene sentido, por eso entramos los valores!
 
  ___
  Talk-es mailing list
  Talk-es@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-es
 
 
 
  ___
  Talk-es mailing list
  Talk-es@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-es
 

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

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 14:57 GMT+02:00 Antonio Navarro anto...@hunos.net:

 Si falta la etiqueta 'name' en una calle, es que no se ha etiquetado. Si
 falta la etiqueta 'oneway' no puedes deducir lo mismo porque sólo se indica
 donde es necesaria (tanto a 'yes' como a 'no' donde se requiera). Entiendo
 que pueda causar incertidumbre si no está, pero no más que cualquier otra
 etiqueta. Es como si en el mapa ves una calle que no tiene farolas. ¿No las
 tiene realmente o no se han etiquetado? ¿Añadimos nodos que digan 'sin
 farola' por todas partes para eliminar incertidumbre?

Pero no estaba hablando de eso!

De todos modos mi contraargumento es que la incertidumbre sobre las
farolas no puede llevar a un choque frontal con un autobus ;).

 Debe ser problema de que me cuesta etiquetar cosas 'en negativo', no hay
 restricción de giro, no hay arboles, no hay restricción de sentido, no
 hay no terminamos nunca :-D

El comentario que hice unos mensajes mas atras sobre el campo booleano
va por ahi precisamente. Creo que hay algo de comportamiento inducido
por la eleccion del tipo de atributo. Es solo una intuicion, puede no ser buena.

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

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Simó Albert i Beltran

Efectivamente, la consulta que te he pasado muestra todos los ways que
tienen la clave oneway, con cualquier valor.

Las zonas amarillas de la consulta que has mandado son el interior de un
poligono, un way cerrado. Salen muchos porque estas seleccionando
todos los ways que no tengan estos valores, incluido los que no son ni
careteras, ni calles, ni caminos...

La siguiente consulta selecciona los ways que tengan la clave
highway y no tengan la clave oneway.

http://overpass-turbo.eu/s/4Ls


pgpuwFpJDzx04.pgp
Description: PGP signature
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] doble sentido de las calles

2014-08-28 Thread Simó Albert i Beltran

highway=motorway_link implica oneway=yes


pgpQPdXjT9BOg.pgp
Description: PGP signature
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-at] Brücken

2014-08-28 Thread Gabriel Pfuner


 Gesendet: Mittwoch, 27. August 2014 um 22:01 Uhr
 Von: David Schmitt da...@black.co.at
 An: talk-at@openstreetmap.org
 Betreff: Re: [Talk-at] Brücken

 On 2014-08-27 20:39, Gabriel Pfuner wrote:
  Wann ist ein Name ein richtiger Name?
 
 Nach meinem OSM-Verständnis, dann wenn die lokale Bevölkerung ein Ding 
 so bezeichnet. Namen auf Schildern und anderen Karten sind da natürlich 
 gute Hinweise, aber Vorrang hat die sogenannte ground truth.
 
 Um evt. Konflikten vorzubeugen gibt es dann natürlich alt_name und 
 ähnliches.
 

Da schließe ich mich an, allerdings muss man mM noch wesentlich strenger bei 
der Auswahl sein. 
Siehe zB das Beispiel im Wiki artikel dazub ( 
http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Autobahnbr%C3%BCcken )

... (z.B. GERINNE BEI PRESSBAUM - Brücke über ein Gerinne bei Pressbaum 
?). ...

Wenn nichtmal die Asfinag sich die Mühe macht die Brücke ordentlich zu 
benennen, dann hat vl das Gerinne einfach keinen Namen, oder einen Namen dan 
man nur sehr begrenzt Lokal kennt und langsam vergessen wird. 

Was hat es für einen Sinn irgendwelche kleinen Konstruktiven Durchlässe, 
MiniBrücken etc zu benennen, vorallem mit so Aussagekräftigen Namen wie 
Gerinne über bei/vor/nahe xy oder Weg bei/von xy Das sind ja keine Namen 
sondern vielmehr Beschreibungen. Wenn man es einträgt dann bitte so das die 
Namen nicht auf der Karte dargestellt werden, ansonsten wird es sehr 
uninteressant wenn auf der Karte alle paar hundert Meter irgendeine 
Brückenbeschreibung auftaucht. zB Weg bei Ornding diese Bezeichnung gibt es 
bei KM 88,2 KM 88,9 KM 88,7 und KM 88,5. Und solche gibt es viele in dieser 
Liste.

Kurzum ich bin nicht dafür das Brücken mit Weg bei xy oder Gerinne bei xy 
benannt werden. Ähnlich verhält es sich bei den Nummern/Kürzel, diese werden 
sowieso nur Asfinag intern verwendet.

mfg gabriel

 

 
 MfG David
 
 
 ___
 Talk-at mailing list
 Talk-at@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-at


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

Re: [Talk-at] Karte zur Gebäudeabdeckung in Österreich

2014-08-28 Thread Markus Straub

Wow, gratuliere, die Karte ist wirklich wunderschön geworden!
Gibt nichts zu meckern, einfach tolle Arbeit.

LG,
Markus

2014-08-26 8:24 GMT+02:00 Thomas Konrad tkon...@gmx.net:
 Hallo,

 ich habe vor kurzem eine Karte erstellt, die die Gebäudeabdeckung in
 Österreich zeigt:

 http://thomaskonrad.at/2014/08/analyse-der-openstreetmap-gebaudeabdeckung-in-osterreich/

 Die Karte soll als Analysewerkzeug und Motivation dienen, die Situation in
 Österreich zu verbessern :) Ganz unten im Artikel gibt es technische Infos,
 wie ich die Karte erstellt habe. Ich freue mich über Feedback!

 Liebe Grüße
 Tom

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


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

Re: [Talk-at] Karte zur Gebäudeabdeckung in Österreich

2014-08-28 Thread Stefan Tauner

On Tue, 26 Aug 2014 08:24:09 +0200
Thomas Konrad tkon...@gmx.net wrote:

 Hallo,
 
 ich habe vor kurzem eine Karte erstellt, die die Gebäudeabdeckung in 
 Österreich zeigt:
 
 http://thomaskonrad.at/2014/08/analyse-der-openstreetmap-gebaudeabdeckung-in-osterreich/
 
 Die Karte soll als Analysewerkzeug und Motivation dienen, die Situation in 
 Österreich zu verbessern :) Ganz unten im Artikel gibt es technische Infos, 
 wie ich die Karte erstellt habe. Ich freue mich über Feedback!

Ein optionaler Mapnik layer wär noch ein Hit, ansonsten hab nicht
einmal ich was zu raunzen... :)

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

Re: [Talk-at] Karte zur Gebäudeabdeckung in Österreich / JOSM Areaselector

2014-08-28 Thread Paul Woelfel

Hallo,

Passend zur Grbäudeabdeckung hab ich mit Unterstützung von Tom ein Tool
erstellt, welches es leichter macht Gebäude aus basemap.at Bildern zu
mappen.

Das Plugin für JOSM nennt sich Areaselector und is auch in den normalen
Josm Plugins gelistet. Quellcode und ist unter
https://github.com/JOSM/JOSM-areaselector zu finden.

Zum mappen eines Gebäudes muss man nur den Bereich des Gebäudes anklicken
und es werden automatisch die Grenzen erkannt und ein Polygon gezeichnet.
Ein Tagging Dialog, welcher sich die letzten Werte merkt, wird danach
automatisch angezeigt.

Mir is klar, dass die basemap Daten nicht immer hundertprozentig richtig
ist, aber ich denke als Basis mal nicht schlecht.

Ich würde mich auch über Feedback oder Codebeiträge freuen!


Mit freundlichen Grüßen
Dipl.-Ing. Paul Wölfel

Email paul.woel...@gmail.com
Tel. +43 664 88 499 513
Lindengasse 31/1/11
1070 Wien
Austria

Am 28.08.2014 21:37 schrieb Markus Straub markus.straub...@gmail.com:

 Wow, gratuliere, die Karte ist wirklich wunderschön geworden!
 Gibt nichts zu meckern, einfach tolle Arbeit.

 LG,
 Markus

 2014-08-26 8:24 GMT+02:00 Thomas Konrad tkon...@gmx.net:
  Hallo,
 
  ich habe vor kurzem eine Karte erstellt, die die Gebäudeabdeckung in
  Österreich zeigt:
 
 
 http://thomaskonrad.at/2014/08/analyse-der-openstreetmap-gebaudeabdeckung-in-osterreich/
 
  Die Karte soll als Analysewerkzeug und Motivation dienen, die Situation
 in
  Österreich zu verbessern :) Ganz unten im Artikel gibt es technische
 Infos,
  wie ich die Karte erstellt habe. Ich freue mich über Feedback!
 
  Liebe Grüße
  Tom
 
  ___
  Talk-at mailing list
  Talk-at@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-at
 

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

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

Re: [Talk-at] Karte zur Gebäudeabdeckung in Österreich / JOSM Areaselector

2014-08-28 Thread Stefan Tauner

On Thu, 28 Aug 2014 21:53:34 +0200
Paul Woelfel paul.woel...@gmail.com wrote:

 Hallo,
 
 Passend zur Grbäudeabdeckung hab ich mit Unterstützung von Tom ein Tool
 erstellt, welches es leichter macht Gebäude aus basemap.at Bildern zu
 mappen.


Endlich... danke! :) Ich hab mich mit scanaerial rumgespielt, um das
selbe für die ViennaGIS-Karten zu erreichen, aber das funktionierte nie
sinnvoll und ich war immer zu faul, in den Code zu schauen...

Funktioniert schon ziemlich gut, aber aus den Ergebnissen zu urteilen,
versuchst du die innere Fläche zu matchen und nicht den dunkleren Rand
(hab mir den Code nicht angesehen). Dadurch werden viele Ecken nicht
rechtwinkelig, obwohl sie es sind und außerdem werden die Gebäude
schlußendlich zu klein.

Außerdem beziehst du dich nur auf sichtbare Kacheln, was auch ein
Problem ist, da bei höheren Zoomlevels manche größere Gebäude nicht
mehr komplett drauf passen. Da fehlen dann unter Umständen einige
Details.

Beides merkt man noch stärker beim ViennaGIS-Mehrzweckkarten-Layer BTW.

Auf jeden Fall ist das eine immense Beschleunigung der
Gebäude-Erfassung, vielen Dank. Das gehört ordentlich promoted...

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

Re: [Talk-at] Karte zur Gebäudeabdeckung in Österreich / JOSM Areaselector

2014-08-28 Thread Paul Woelfel

Jap is richtig, ich geh auf die Fläche. Durch div Operatoren aber passt die
Fläche relativ gut auch zu den Kanten. Der Areaselector funktioniert in
allen Zoomstufen, in manchen natürlich besser. Wir haben auch probiert den
Zoomlevel auf das richtige zu setzten, sind aber noch nicht auf einen
grünen Zweig gelangt.


Mit freundlichen Grüßen
Dipl.-Ing. Paul Wölfel

Email paul.woel...@gmail.com
Tel. +43 664 88 499 513
Lindengasse 31/1/11
1070 Wien
Austria

Am 28.08.2014 22:15 schrieb Stefan Tauner stefan.tau...@gmx.at:

 On Thu, 28 Aug 2014 21:53:34 +0200
 Paul Woelfel paul.woel...@gmail.com wrote:

  Hallo,
 
  Passend zur Grbäudeabdeckung hab ich mit Unterstützung von Tom ein Tool
  erstellt, welches es leichter macht Gebäude aus basemap.at Bildern zu
  mappen.
 

 Endlich... danke! :) Ich hab mich mit scanaerial rumgespielt, um das
 selbe für die ViennaGIS-Karten zu erreichen, aber das funktionierte nie
 sinnvoll und ich war immer zu faul, in den Code zu schauen...

 Funktioniert schon ziemlich gut, aber aus den Ergebnissen zu urteilen,
 versuchst du die innere Fläche zu matchen und nicht den dunkleren Rand
 (hab mir den Code nicht angesehen). Dadurch werden viele Ecken nicht
 rechtwinkelig, obwohl sie es sind und außerdem werden die Gebäude
 schlußendlich zu klein.

 Außerdem beziehst du dich nur auf sichtbare Kacheln, was auch ein
 Problem ist, da bei höheren Zoomlevels manche größere Gebäude nicht
 mehr komplett drauf passen. Da fehlen dann unter Umständen einige
 Details.

 Beides merkt man noch stärker beim ViennaGIS-Mehrzweckkarten-Layer BTW.

 Auf jeden Fall ist das eine immense Beschleunigung der
 Gebäude-Erfassung, vielen Dank. Das gehört ordentlich promoted...

 --
 Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

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

Re: [Talk-ca] Confusing CanVec import: Elliot Lake

2014-08-28 Thread Stewart C. Russell

On 14-08-28 01:44 AM, James Ewen wrote:
 
 OSM is a living entity that changes.

I know this, James. But an edit should change the map for the better.
There were trails along Horne Lake, trails with boardwalks and bridges
that I walked and mapped by hand. But that work's gone — foom! —
replaced with an imported Horne Lake, v1 with land use polygons that
aren't even clipped to the lakeshore.

 So have a bit of a look into what CanVec is … You'll find
 these artifacts all over.

I'd like to suggest that, if an import breaks a country into
Minecraft-like square blocks, you're doing it wrong.

Many of the import guidelines were broken here, too. Is the CanVec
import process described in the wiki moribund? If there had been some
discussion here about imports in the 041J locale, I'd have relished the
opportunity to help fuse imported and source=survey data.

 Large complicated polygons abound in the OSM database. They just need
 to be dealt with appropriately.

Import/Guidelines recommends simplifying shapes
http://wiki.openstreetmap.org/wiki/Import/Guidelines#Consider_simplifying,
and MapShaper — the suggested tool — uses a couple of appropriate
algorithms.

 Everyone's contributions are
 appreciated, but occasionally we bump into each other.

Yeah, but as a pedestrian, I stood no chance against CanvecImports'
steamroller.

cheers,
 Stewart



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

Re: [Talk-ca] Confusing CanVec import: Elliot Lake

2014-08-28 Thread Daniel Begin

I give a big +1 to James' comments

-Original Message-
From: James Ewen [mailto:ve6...@gmail.com] 

... existing data usually stays. Obviously a mistake was made. We're all human.
... whichever source has the best resolution should be the one that stays, or 
perhaps a merge of the best data from both...
... OSM is a living entity that changes.
... you've found an area of concern, and Andrew is responding. You can't get 
much better than this.
... should we take your Horne Lake closed polygon and simplify it down to 20 
points? [...] who defines sensible?

... And of course, thank you to both of you for all the work you guys ave done 
in adding to the OSM database. Everyone's contributions are appreciated, but 
occasionally we bump into each other. This forum gives us the perfect place to 
say Oops, excuse me... sorry!



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

Re: [Talk-ca] Confusing CanVec import: Elliot Lake

2014-08-28 Thread Andrew

Hello:
For what it's worth I've downloaded the changeset (# 20327545 ) around
Horner lake and there wasn't any trails there prior to my upload. I'll
continue to investigate.

Andrew
aka CanvecImports


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

Re: [Talk-cz] Odstávka LPIS

2014-08-28 Thread Zdeněk Pražák

mohu se zeptat jaké jsou nové zprávy o traceru lpis
Pražák


Dne 26. srpna 2014 19:24 Marián Kyral mky...@email.cz napsal(a):

  Tak web jede, wms (podkladová mapa) taky, ale WFS, které v traceru
 používám, bohužel ne. Servis sice jede, ale v podstatě nic v něm není.
 Uvidíme, jestli to během zítřka opraví. Když tak jim budu muset napsat,

 Marián

 Dne 23.8.2014 21:28, Marián Kyral napsal(a):

 Takže LPIS WFS a WMS je dole. Doufám, že ta nová verze nic nepokazí :-D

 Marián

 Dne 22.8.2014 17:23, Marián Kyral napsal(a):

 Ahoj,
 tak jsem teď zavítal na webové rozhraní LPIS a co tam nevidím:

 Plánovaná odstávka registru půdy (LPIS)

 19.8.2014


 *V termínu 21.8. od 20h do 26.8. do 18h budou prováděny úpravy v registru
 půdy (LPIS). V tomto termínu nebude dostupné webové rozhraní veřejného LPIS
 a LPISu pro farmáře. Nedostupné budou také WMS služby a veřejné webové
 služby LPIS. Částečné omezení bude také v aplikacích napojených na LPIS a
 to, Data ke stažení, EPH, IZR a dále Registru vinic (RV). Odstávka se týká
 přípravy spuštění nové evidence půdy (LPIS). *


 http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html

 Tracer zatím funguje, ale až přestane, tak mi nenadávejte. Vypadá to, že
 budu mít čas i na něco jiného ;-)

 Marián



 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz




 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz



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


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

Re: [Talk-cz] Odstávka LPIS

Zeptat se můžeš.
Včera odpoledne jsem jim psal. Sice zatím neodpověděli, nicméně nějaké změny
tam byly. Momentálně mi dotaz na LPIS_FB4_BBOX a LPIS_FB4_01 vrátí
databázovou chybu. Čekám, jestli to opraví, nebo jestli jim mám znova
napsat.

V každém případě, až to plně zprovozní, budu muset vydat novou verzi
Traceru, neb místo LPIS_FB4 je teď LPIS_FB4_01. Takže by to sice tracovalo,
ale bez vyplnění landuse.

Marián

-- Původní zpráva --
Od: Zdeněk Pražák zpra...@seznam.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 28. 8. 2014 10:33:09
Předmět: Re: [Talk-cz] Odstávka LPIS

mohu se zeptat jaké jsou nové zprávy o traceru lpis

Pražák

Dne 26. srpna 2014 19:24 Marián Kyral mky...@email.cz
(mailto:mky...@email.cz) napsal(a):

Tak web jede, wms (podkladová mapa) taky, ale WFS, které v traceru používám,
bohužel ne. Servis sice jede, ale v podstatě nic v něm není. Uvidíme, jestli
to během zítřka opraví. Když tak jim budu muset napsat,

Marián

Dne 23.8.2014 21:28, Marián Kyral napsal(a):

Takže LPIS WFS a WMS je dole. Doufám, že ta nová verze nic nepokazí :-D

Marián

Dne 22.8.2014 17:23, Marián Kyral napsal(a):

Ahoj,
tak jsem teď zavítal na webové rozhraní LPIS a co tam nevidím:

Plánovaná odstávka registru půdy (LPIS)

19.8.2014

V termínu 21.8. od 20h do 26.8. do 18h budou prováděny úpravy v registru
půdy (LPIS). V tomto termínu nebude dostupné webové rozhraní veřejného LPIS
a LPISu pro farmáře. Nedostupné budou také WMS služby a veřejné webové
služby LPIS. Částečné omezení bude také v aplikacích napojených na LPIS a
to, Data ke stažení, EPH, IZR a dále Registru vinic (RV). Odstávka se týká
přípravy spuštění nové evidence půdy (LPIS).

http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html
(http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html)

Tracer zatím funguje, ale až přestane, tak mi nenadávejte. Vypadá to, že
budu mít čas i na něco jiného ;-)

Marián

___
Talk-cz mailing list
a href='mailto:Talk-cz@openstreetmap.org'Talk-cz@openstreetmap.org/a
a
href='https://lists.openstreetmap.org/listinfo/talk-cz'https://lists.openstreetmap.org/listinfo/talk-cz/a

___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)

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

Re: [Talk-cz] Kontrola a doplnění ulic

2014-08-28 Thread Marek Chlup

Ahoj.

Jsem jen občasný přispěvatel a OSMi jsem neznal. Děkuji za info.

Již jsem se párkrát a nyní i znovu s užitím OSMi setkal s problémem
velkých a malých písmen v názvech ulic. Například v Olomouci je ulice:
Na Střelnici
To je pojmenování ulice v OSM. OSMi však zde červená asi proto, že
adresní body mají:
Na střelnici

Díval jsem s do jiných map:
Google mapy: Na střelnici
Seznam mapy: Na Střelnici

Adresní body jsou jak chápu původem s RUIAN (respektive uir_adr).

Pravidla možná nemusí být vždy jednoznačná:
http://prirucka.ujc.cas.cz/?id=186
Jelikož se občas mohou čtyři hádat (alespoň dle mne) jestli je to dle
obecného jména nebo vlastního.

Jaký etalon mám považovat za správný? Že by ceduli co tam je přibitá:-)?

Ahoj
Marek

On Wed, Aug 27, 2014 at 09:45:11PM +0200, Marián Kyral wrote:
 Ahoj,
 když teď máme v OSM skoro všechny adresy, nebylo by na škodu a
 pokračovat dalším krokem a tím je kontrola ulic.
 
 OSM inspektor asi všichni znají, ale pro jistotu:
 
 1) Do prohlížeče zadat adresu http://tools.geofabrik.de/osmi/
 2) Vybrat View: Addresses a odškrknout volbu No addr:street tag
 3) Přiblížit si svou oblast zájmu a hledat červené tečky - tam jsou
 problémy. Viz příloha.
 4) Pro jistotu si to ještě více přiblížit, aby byly vidět spojovací čáry
 s ulicí - občas to vede i několik desítek kilometrů daleko, do další
 vesnice/městečka kde mají stejnou ulici.
 5) Otevřít si danou oblast v editoru a opravit nalezené problémy
 
 Pro práci se hodí vrstva ulic z RUIAN od Petra:
 
 tms[20]:http://tile.poloha.net/ulice/{zoom}/{x}/{y}.png 
 
 Nicméně doporučuji slepě nevěřit a raději dvakrát překontrolovat a při
 editaci myslet. Občas se objeví různé kuriozity (většinou asi vzniklé
 historickým vývojem).
 
 Lovu zdar ;-)
 Marián


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


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

Re: [Talk-cz] Kontrola a doplnění ulic

2014-08-28 Thread Jan Martinec

Dne 28.8.2014 v 12:09 Marek Chlup napsal(a):
Ahoj.

Jsem jen občasný přispěvatel a OSMi jsem neznal. Děkuji za info.

Již jsem se párkrát a nyní i znovu s užitím OSMi setkal s problémem
velkých a malých písmen v názvech ulic. Například v Olomouci je ulice:
Na Střelnici
To je pojmenování ulice v OSM. OSMi však zde červená asi proto, že
adresní body mají:
Na střelnici

Díval jsem s do jiných map:
Google mapy: Na střelnici
Seznam mapy: Na Střelnici

Adresní body jsou jak chápu původem s RUIAN (respektive uir_adr).

Pravidla možná nemusí být vždy jednoznačná:
http://prirucka.ujc.cas.cz/?id=186
Jelikož se občas mohou čtyři hádat (alespoň dle mne) jestli je to dle
obecného jména nebo vlastního.

Jaký etalon mám považovat za správný? Že by ceduli co tam je přibitá:-)?

Ahoj,
přesně tak - konečně i ÚJČ píše Některé obecní, městské úřady a magistráty
stále setrvávají u staršího způsobu psaní, zejména pokud jde o předložková
spojení (viz bod 2.1). a mapa by měla reflektovat realitu, ne Pravidla českého
pravopisu.

Nicméně: ten problém s adresami ale je větší: velká a malá písmena bych
považoval za ne-problém, to funguje při vyhledávání téměř všude (takže bych to
neřešil a považoval za false positive); ale co se zkratkami? Třeba celý úsek
podél Mariánských hradeb v Praze: ulice má name=Na Baště svaté Ludmily,
zatímco adresní body Na Baště sv. Ludmily.

Tedy dotaz do pléna: má smysl řešit takové (významově rovnocenné) rozdíly?
(Případně, pokud ne: lze v OSMi něco označit jako fixed: false positive?)

Honza Piškvor Martinec

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

Re: [Talk-cz] Kontrola a doplnění ulic

2014-08-28 Thread Jan Kouba

Dne Čt 28. srpna 2014 12:09:56, Marek Chlup napsal(a):
 Ahoj.
 
 Jsem jen občasný přispěvatel a OSMi jsem neznal. Děkuji za info.
 
 Již jsem se párkrát a nyní i znovu s užitím OSMi setkal s problémem
 velkých a malých písmen v názvech ulic. Například v Olomouci je ulice:
 Na Střelnici
 To je pojmenování ulice v OSM. OSMi však zde červená asi proto, že
 adresní body mají:
 Na střelnici
 
 Díval jsem s do jiných map:
 Google mapy: Na střelnici
 Seznam mapy: Na Střelnici
 
 Adresní body jsou jak chápu původem s RUIAN (respektive uir_adr).
 
 Pravidla možná nemusí být vždy jednoznačná:
 http://prirucka.ujc.cas.cz/?id=186
 Jelikož se občas mohou čtyři hádat (alespoň dle mne) jestli je to dle
 obecného jména nebo vlastního.
 
 Jaký etalon mám považovat za správný? Že by ceduli co tam je přibitá:-)?

Na té ceduli to stejně nejspíš bude všechno velkýma (NA STŘELNICI). Zdá se mi, 
že všechny cedule s názvy (ulice, města, názvy turistických rozcestníků, ...) 
se schválně píší pouze velkými písmeny, aby v tom neudělali náhodou chybu, 
nebo aby se to nemuselo předělávat, když zase provedou nějakou změnu v psaní 
velkých písmen.

Zrovna v tom případě turistických rozcestníků už jsem uvažoval o tom, jestli 
by nebylo lepší do tagu name psát opravdu to, co je na rozcestníku napsáno 
(tj. všechna písmena velká). Nakonec jsem to ale zavrhnul, protože to tak 
nikdo nedělá a vypadá to divně.


Jan Kouba
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Kontrola a doplnění ulic

2014-08-28 Thread Petr Morávek [Xificurk]

Dne 28.8.2014 12:51, Jan Kouba napsal(a):
 Na té ceduli to stejně nejspíš bude všechno velkýma (NA STŘELNICI). Zdá se 
 mi, 
 že všechny cedule s názvy (ulice, města, názvy turistických rozcestníků, ...) 
 se schválně píší pouze velkými písmeny, aby v tom neudělali náhodou chybu, 
 nebo aby se to nemuselo předělávat, když zase provedou nějakou změnu v psaní 
 velkých písmen.

Tohle není vůbec pravda, viz např.:
https://www.dropbox.com/s/j9qpysu5qiss19d/k-visnovce.png?dl=0

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Kontrola a doplnění ulic

2014-08-28 Thread Václav Řehák

Dne 28. srpna 2014 13:00 Petr Morávek [Xificurk] p...@pada.cz napsal(a):

 Dne 28.8.2014 12:51, Jan Kouba napsal(a):
  Na té ceduli to stejně nejspíš bude všechno velkýma (NA STŘELNICI). Zdá
 se mi,
  že všechny cedule s názvy (ulice, města, názvy turistických rozcestníků,
 ...)
  se schválně píší pouze velkými písmeny, aby v tom neudělali náhodou
 chybu,
  nebo aby se to nemuselo předělávat, když zase provedou nějakou změnu v
 psaní
  velkých písmen.

 Tohle není vůbec pravda, viz např.:
 https://www.dropbox.com/s/j9qpysu5qiss19d/k-visnovce.png?dl=0


Jak kde. V konkrétní ulici v Olomouci je to také rozlišeno:
https://www.google.cz/maps/@49.599926,17.250687,3a,15y,39.99h,91.34t/data=!3m4!1e1!3m2!1sHW5WKmB_iFe85YF31XiKSg!2e0

Ale třeba v Praze se to opravdu píše velkými:
https://www.google.cz/maps/@50.089705,14.432696,3a,24.4y,172.81h,93.81t/data=!3m4!1e1!3m2!1sAnRuGzCnVzJmBDfOR2g6ng!2e0

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

Re: [Talk-cz] Odstávka LPIS

Požadavek byl předán k řešení. Tož uvidíme.

Celé odpoledne budu pryč, takže další update nejdříve večer.
Marián

-- Původní zpráva --
Od: Marián Kyral mky...@email.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 28. 8. 2014 10:42:16
Předmět: Re: [Talk-cz] Odstávka LPIS

V každém případě, až to plně zprovozní, budu muset vydat novou verzi
Traceru, neb místo LPIS_FB4 je teď LPIS_FB4_01. Takže by to sice tracovalo,
ale bez vyplnění landuse.

Marián

-- Původní zpráva --
Od: Zdeněk Pražák zpra...@seznam.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 28. 8. 2014 10:33:09
Předmět: Re: [Talk-cz] Odstávka LPIS

mohu se zeptat jaké jsou nové zprávy o traceru lpis

Pražák

Dne 26. srpna 2014 19:24 Marián Kyral mky...@email.cz
(mailto:mky...@email.cz) napsal(a):

Marián

Dne 23.8.2014 21:28, Marián Kyral napsal(a):

Takže LPIS WFS a WMS je dole. Doufám, že ta nová verze nic nepokazí :-D

Marián

Dne 22.8.2014 17:23, Marián Kyral napsal(a):

Ahoj,
tak jsem teď zavítal na webové rozhraní LPIS a co tam nevidím:

Plánovaná odstávka registru půdy (LPIS)

19.8.2014

http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html
(http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html)

Tracer zatím funguje, ale až přestane, tak mi nenadávejte. Vypadá to, že
budu mít čas i na něco jiného ;-)

Marián

___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)

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

Re: [Talk-cz] Kontrola a doplnění ulic

2014-08-28 Thread Jan Martinec

Dne 28.8.2014 v 13:30 Václav Řehák napsal(a):
 
 
 
 Dne 28. srpna 2014 13:00 Petr Morávek [Xificurk] p...@pada.cz
 mailto:p...@pada.cz napsal(a):
 
 Dne 28.8.2014 12:51, Jan Kouba napsal(a):
  Na té ceduli to stejně nejspíš bude všechno velkýma (NA STŘELNICI). Zdá 
 se mi,
  že všechny cedule s názvy (ulice, města, názvy turistických 
 rozcestníků, ...)
  se schválně píší pouze velkými písmeny, aby v tom neudělali náhodou 
 chybu,
  nebo aby se to nemuselo předělávat, když zase provedou nějakou změnu v 
 psaní
  velkých písmen.
 
 Tohle není vůbec pravda, viz např.:
 https://www.dropbox.com/s/j9qpysu5qiss19d/k-visnovce.png?dl=0
 
 
 Jak kde. V konkrétní ulici v Olomouci je to také rozlišeno:
 https://www.google.cz/maps/@49.599926,17.250687,3a,15y,39.99h,91.34t/data=!3m4!1e1!3m2!1sHW5WKmB_iFe85YF31XiKSg!2e0
 
 Ale třeba v Praze se to opravdu píše velkými:
 https://www.google.cz/maps/@50.089705,14.432696,3a,24.4y,172.81h,93.81t/data=!3m4!1e1!3m2!1sAnRuGzCnVzJmBDfOR2g6ng!2e0
 
I v Praze jak kde - to je spíš otázka vizuálního stylu než zaseknutej Capslock
;) Pražské uliční cedule mají jednotný kapitálkový styl, ale ukazatele už ne.
https://www.google.cz/maps/@50.087195,14.570886,3a,32.9y,125.74h,88.99t/data=!3m4!1e1!3m2!1srFgKs2MKSjj2c-KELmeDmA!2e0!6m1!1e1

HPM


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

Re: [Talk-cz] Odstávka LPIS

Zatím žádná změna. Snad zítra.

Marián

Dne 28.8.2014 15:18, Marián Kyral napsal(a):
 Požadavek byl předán k řešení. Tož uvidíme.

 Celé odpoledne budu pryč, takže další update nejdříve večer.
 Marián

 -- Původní zpráva --
 Od: Marián Kyral mky...@email.cz
 Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
 Datum: 28. 8. 2014 10:42:16
 Předmět: Re: [Talk-cz] Odstávka LPIS


 Zeptat se můžeš.
 Včera odpoledne jsem jim psal. Sice zatím neodpověděli, nicméně
 nějaké změny tam byly. Momentálně mi dotaz na LPIS_FB4_BBOX a
 LPIS_FB4_01 vrátí databázovou chybu. Čekám, jestli to opraví, nebo
 jestli jim mám znova napsat.

 V každém případě, až to plně zprovozní, budu muset vydat novou
 verzi Traceru, neb místo LPIS_FB4 je teď LPIS_FB4_01. Takže by to
 sice tracovalo, ale bez vyplnění landuse.

 Marián

 -- Původní zpráva --
 Od: Zdeněk Pražák zpra...@seznam.cz
 Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
 Datum: 28. 8. 2014 10:33:09
 Předmět: Re: [Talk-cz] Odstávka LPIS


 mohu se zeptat jaké jsou nové zprávy o traceru lpis
 Pražák


 Dne 26. srpna 2014 19:24 Marián Kyral mky...@email.cz
 mailto:mky...@email.cz napsal(a):

 Tak web jede, wms (podkladová mapa) taky, ale WFS, které v
 traceru používám, bohužel ne. Servis sice jede, ale v
 podstatě nic v něm není. Uvidíme, jestli to během zítřka
 opraví. Když tak jim budu muset napsat,

 Marián

 Dne 23.8.2014 21:28, Marián Kyral napsal(a):

 Takže LPIS WFS a WMS je dole. Doufám, že ta nová verze
 nic nepokazí :-D

 Marián

 Dne 22.8.2014 17:23, Marián Kyral napsal(a):

 Ahoj,
 tak jsem teď zavítal na webové rozhraní LPIS a co
 tam nevidím:


   Plánovaná odstávka registru půdy (LPIS)

 19.8.2014

 *V termínu 21.8. od 20h do 26.8. do 18h budou
 prováděny úpravy v registru půdy (LPIS). V tomto
 termínu nebude dostupné webové rozhraní veřejného
 LPIS a LPISu pro farmáře. Nedostupné budou také
 WMS služby a veřejné webové služby LPIS. Částečné
 omezení bude také v aplikacích napojených na LPIS
 a to, Data ke stažení, EPH, IZR a dále Registru
 vinic (RV). Odstávka se týká přípravy spuštění
 nové evidence půdy (LPIS).
 *


 
 http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html

 Tracer zatím funguje, ale až přestane, tak mi
 nenadávejte. Vypadá to, že budu mít čas i na něco
 jiného ;-)

 Marián*
 *



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

Re: [Talk-cz] Kontrola a doplnění ulic

Dne 28.8.2014 12:50, Jan Martinec napsal(a):

 Nicméně: ten problém s adresami ale je větší: velká a malá písmena bych
 považoval za ne-problém, to funguje při vyhledávání téměř všude (takže bych to
 neřešil a považoval za false positive); ale co se zkratkami? Třeba celý úsek
 podél Mariánských hradeb v Praze: ulice má name=Na Baště svaté Ludmily,
 zatímco adresní body Na Baště sv. Ludmily.

 Tedy dotaz do pléna: má smysl řešit takové (významově rovnocenné) rozdíly?
 (Případně, pokud ne: lze v OSMi něco označit jako fixed: false positive?)

 Honza Piškvor Martinec


Přesně tak. Co vím, je snaha v OSM mít nezkrácené názvy. Existuje
dokonce skript, který projde seznam ulic a navrhne nezkrácené jméno -
ul. - ulice, tř. - třída, nám. - náměstím, náb. - nábřeží...

Na cedulích se to většinou zkracuje - cedule je menší a levnější. A pak
zřejmě záleží na konkrétním úředníkovi, jak to zadá do databáze a
následně do RUIAN.
Takže pokud bychom to chtěli udělat dle pravidel OSM - tedy nezkracovat,
musel by si Petr udělat nějaké mapování - RUIAN ulice - nezkrácená OSM
ulice. A při aktualizaci k tomu přihlížet.

Marián

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

Re: [Talk-cz] Kontrola a doplnění ulic

2014-08-28 Thread Petr Morávek [Xificurk]

Dne 28.8.2014 20:50, Marián Kyral napsal(a):
 Dne 28.8.2014 12:50, Jan Martinec napsal(a):
 
 Nicméně: ten problém s adresami ale je větší: velká a malá písmena bych
 považoval za ne-problém, to funguje při vyhledávání téměř všude (takže bych 
 to
 neřešil a považoval za false positive); ale co se zkratkami? Třeba celý úsek
 podél Mariánských hradeb v Praze: ulice má name=Na Baště svaté Ludmily,
 zatímco adresní body Na Baště sv. Ludmily.

 Tedy dotaz do pléna: má smysl řešit takové (významově rovnocenné) rozdíly?
 (Případně, pokud ne: lze v OSMi něco označit jako fixed: false positive?)

 Honza Piškvor Martinec

 
 Přesně tak. Co vím, je snaha v OSM mít nezkrácené názvy. Existuje
 dokonce skript, který projde seznam ulic a navrhne nezkrácené jméno -
 ul. - ulice, tř. - třída, nám. - náměstím, náb. - nábřeží...
 
 Na cedulích se to většinou zkracuje - cedule je menší a levnější. A pak
 zřejmě záleží na konkrétním úředníkovi, jak to zadá do databáze a
 následně do RUIAN.
 Takže pokud bychom to chtěli udělat dle pravidel OSM - tedy nezkracovat,
 musel by si Petr udělat nějaké mapování - RUIAN ulice - nezkrácená OSM
 ulice. A při aktualizaci k tomu přihlížet.
 
 Marián

Ona by se nějaká ta normalizace názvů asi hodila, protože jak jsem
koukal do RUIAN, tak je tam docela bordel. Jednou jsou jména pokrácena,
jindy ne. Jednou je na začátku velké písmeno, jindy ne. Často se taky
vyskytuje typografický nešvar, že za tečkou není mezera atp. A to
všechno ve všech možných kombinacích.

Petr

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

Re: [Talk-cz] Kontrola a doplnění ulic

2014-08-28 Thread Jan Dudík

On je hlavní problém s ulicemi pojmenovanými po lidech.
Dvořákova / A. Dvořáka / Ant. Dvořáka / Antonína Dvořáka - vše je
de-facto správně.

příklad z ČB: Rudolfovská / Rudolfovská tř. / rudolfovská třída

JD



Dne 28. srpna 2014 20:50 Marián Kyral mky...@email.cz napsal(a):
 Dne 28.8.2014 12:50, Jan Martinec napsal(a):

 Nicméně: ten problém s adresami ale je větší: velká a malá písmena bych
 považoval za ne-problém, to funguje při vyhledávání téměř všude (takže bych 
 to
 neřešil a považoval za false positive); ale co se zkratkami? Třeba celý úsek
 podél Mariánských hradeb v Praze: ulice má name=Na Baště svaté Ludmily,
 zatímco adresní body Na Baště sv. Ludmily.

 Tedy dotaz do pléna: má smysl řešit takové (významově rovnocenné) rozdíly?
 (Případně, pokud ne: lze v OSMi něco označit jako fixed: false positive?)

 Honza Piškvor Martinec


 Přesně tak. Co vím, je snaha v OSM mít nezkrácené názvy. Existuje
 dokonce skript, který projde seznam ulic a navrhne nezkrácené jméno -
 ul. - ulice, tř. - třída, nám. - náměstím, náb. - nábřeží...

 Na cedulích se to většinou zkracuje - cedule je menší a levnější. A pak
 zřejmě záleží na konkrétním úředníkovi, jak to zadá do databáze a
 následně do RUIAN.
 Takže pokud bychom to chtěli udělat dle pravidel OSM - tedy nezkracovat,
 musel by si Petr udělat nějaké mapování - RUIAN ulice - nezkrácená OSM
 ulice. A při aktualizaci k tomu přihlížet.

 Marián

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

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

Re: [Talk-cz] Kontrola a doplnění ulic