[OSM-talk] Barriers of Entry

[Frederik Ramm]

Hi,

   there are many different types of barriers. There are of course 
those we tag with barrier, the physical ones. They are used to keep 
unwanted, unauthorized or unsuitable people or vehicles out. There are 
barriers of entry in the form of entrance exams at places like 
universities, with the aim of assessing the likelihood of someone 
succeeding in their studies. And of course there are job interviews, 
where employers sometimes raise the barrier of entry so high that only 
one in 1000 can pass.


Barriers of entry are not always a bad thing; they might keep you and 
from entering a tunnel for which your vehicle is too wide, or they might 
make it less likely for you to spend years at university with little 
chance to earn a degree.


In OpenStreetMap, people sometimes point to our barriers of entry and 
blindly claim that they must be bad for us. The main page not welcoming 
enough, the editor too difficult, the path to signup too cumbersome, and 
on and on.


Now some of this might be true and I don't want to keep people from 
improving the overall OSM user experience.


However one has to keep in mind that what we're doing here is, and will 
always be, more complex than, say, taking your dog for a walk. Making a 
map does require a certain amount of abstract thinking, and of being 
able to picture things in your mind. Taking part in OSM does require a 
certain willingness to engage with a community; OSM is not for loners. 
And so on.


Barriers of entry are good if they accurately reflect the demands that 
lie further down the road. A barrier that prohibits 3m wide vehicles 
from entering a tunnel that will narrow down to less than 3m in the 
middle is not an arbitrary restriction that should be torn down but 
something that helps everyone.


For OpenStreetMap, we don't gain anything from making it look like 
participating in OSM was the easiest thing in the world. You have to 
possess some skills, and you have to be willing to engage with other 
people, or else your contribution is unlikely to be pleasant for you or 
the project. Taking part in OpenStreetMap requires more sophistication 
than, say, tweeting about where you're having dinner.


We must keep that in mind. I think it works reasonably well at the 
moment, more or less by accident. OSMers are very self-selected, you 
don't stumble across OSM (and much less the signup page) unless you 
invest at least a little effort in looking. But this might change if we 
have more exposure in the future.


If we think about design and user friendliness, abolishing barriers of 
entry unquestioningly would do us a huge disservice and only lead to 
frustration on all sides. A barrier of entry that discourages those who 
unlikely to make an edit without breaking 10 things, or those who can 
make an edit but are unlikely to answer a question from another 
community member about it, could be a healthy barrier.


Before someone misunderstands that, I'm not saying we should introduce 
some kind of entry exams or so. Anyone who wants to participate should 
be allowed to. But it should not be our aim to make the whole world want 
to participate because only a fraction of them can.


Bye
Frederik

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

Re: [OSM-talk] Barriers of Entry

[Peter Wendorff]

Hi Frederik

+0.5 to your thoughts.
On the one hand, yes, I agree: We should not aim to make OSM look like 
not needing any skills, but on the other hand there are in fact parts of 
OSM where help with not much more skills than taking a dog for a walk 
is possible.


That is not necessarily the map database itself.
But in reporting bugs via e.g. OSB (at least partly) I see one possible 
source of help.
Specialised Editors to complete particular tasks, that need not much 
efford, could be another one.


I agree, that full-feature-editors (comparable e.g. with JOSM) are not 
possible to use without skills (or they are dangerous to harm the 
database because of users not knowing what they do).
But an address completion editor, where it's easy to fill in post 
codes, streetnames and housenumbers could be useful - easy to use and 
less error prone.


It's true: Users need skills to participate (further) in OSM. But if we 
don't want to only have technophile people with computer skills, we have 
to motivate less skilled people to learn more.


regards
Peter

Am 14.09.2011 09:24, schrieb Frederik Ramm:

Hi,

   there are many different types of barriers. There are of course 
those we tag with barrier, the physical ones. They are used to keep 
unwanted, unauthorized or unsuitable people or vehicles out. There are 
barriers of entry in the form of entrance exams at places like 
universities, with the aim of assessing the likelihood of someone 
succeeding in their studies. And of course there are job interviews, 
where employers sometimes raise the barrier of entry so high that only 
one in 1000 can pass.


Barriers of entry are not always a bad thing; they might keep you and 
from entering a tunnel for which your vehicle is too wide, or they 
might make it less likely for you to spend years at university with 
little chance to earn a degree.


In OpenStreetMap, people sometimes point to our barriers of entry and 
blindly claim that they must be bad for us. The main page not 
welcoming enough, the editor too difficult, the path to signup too 
cumbersome, and on and on.


Now some of this might be true and I don't want to keep people from 
improving the overall OSM user experience.


However one has to keep in mind that what we're doing here is, and 
will always be, more complex than, say, taking your dog for a walk. 
Making a map does require a certain amount of abstract thinking, and 
of being able to picture things in your mind. Taking part in OSM does 
require a certain willingness to engage with a community; OSM is not 
for loners. And so on.


Barriers of entry are good if they accurately reflect the demands that 
lie further down the road. A barrier that prohibits 3m wide vehicles 
from entering a tunnel that will narrow down to less than 3m in the 
middle is not an arbitrary restriction that should be torn down but 
something that helps everyone.


For OpenStreetMap, we don't gain anything from making it look like 
participating in OSM was the easiest thing in the world. You have to 
possess some skills, and you have to be willing to engage with other 
people, or else your contribution is unlikely to be pleasant for you 
or the project. Taking part in OpenStreetMap requires more 
sophistication than, say, tweeting about where you're having dinner.


We must keep that in mind. I think it works reasonably well at the 
moment, more or less by accident. OSMers are very self-selected, you 
don't stumble across OSM (and much less the signup page) unless you 
invest at least a little effort in looking. But this might change if 
we have more exposure in the future.


If we think about design and user friendliness, abolishing barriers of 
entry unquestioningly would do us a huge disservice and only lead to 
frustration on all sides. A barrier of entry that discourages those 
who unlikely to make an edit without breaking 10 things, or those who 
can make an edit but are unlikely to answer a question from another 
community member about it, could be a healthy barrier.


Before someone misunderstands that, I'm not saying we should introduce 
some kind of entry exams or so. Anyone who wants to participate should 
be allowed to. But it should not be our aim to make the whole world 
want to participate because only a fraction of them can.


Bye
Frederik

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



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

Re: [OSM-talk] Barriers of Entry

[Mike N]

  There's no difference between someone who goes through the 
traditional signup process and messes up the data VS someone coming in 
via a Facebook login or the Friendly page and messes up the data. 
It's only a question of scale - do we pick up enough quality users from 
convenient logins to make it worth the trouble?  Perhaps barriers are 
good for regions that are already saturated with mappers.


On 9/14/2011 4:02 AM, Peter Wendorff wrote:

I agree, that full-feature-editors (comparable e.g. with JOSM) are not
possible to use without skills (or they are dangerous to harm the
database because of users not knowing what they do).
But an address completion editor, where it's easy to fill in post
codes, streetnames and housenumbers could be useful - easy to use and
less error prone.


+1
 Customized editors such as the Skobbler Address Game can solicit 
input from those would not otherwise be interested in learning all the 
details.


 Similarly, a one-way street editor which allows anyone to verify and 
correct all the one-way streets that they know about would be a 
candidate for mass participation.



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

Re: [OSM-talk] Barriers of Entry

[ant]

Hi,

On 14.09.2011 09:24, Frederik Ramm wrote:

Barriers of entry are good if they accurately reflect the demands that
lie further down the road. A barrier that prohibits 3m wide vehicles
from entering a tunnel that will narrow down to less than 3m in the
middle is not an arbitrary restriction that should be torn down but
something that helps everyone.


Weird picture. Vehicles have fixed widths, whereas OSM users have the 
ability to learn and to adopt to the demands that come up during the 
process.




For OpenStreetMap, we don't gain anything from making it look like
participating in OSM was the easiest thing in the world. You have to
possess some skills,


-- you have to have the willingness to acquire some skills. The current 
situation seems to be that only those highly ambitious and tireless 
people have a chance to become involved persistently. I think lower 
entry barriers could attract some very good people that would now turn 
away from the project after three hours of effortless fiddling and 
digging around.


cheers
ant

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

[OSM-talk] SOTM blog collection

[pavithran]

can someone post all the blog links here on their SOTM posts ?
Its sad that I can't find any in http://www.openstreetmap.org/diary

Regards,
Pavithran


-- 
pavithran sakamuri
http://look-pavi.blogspot.com

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

Re: [OSM-talk] Barriers of Entry

[Nic Roets]

Barriers to entry are good when they prevent us from doing some thing bad.

On Wed, Sep 14, 2011 at 9:24 AM, Frederik Ramm frede...@remote.org wrote:

 Hi,

   there are many different types of barriers. There are of course those we
 tag with barrier, the physical ones. They are used to keep unwanted,
 unauthorized or unsuitable people or vehicles out.


Congestion e.g. blocking walkways or cycleways is bad. Pollution is bad.

There are barriers of entry in the form of entrance exams at places like
 universities, with the aim of assessing the likelihood of someone succeeding
 in their studies.


Students keeping the professors busy with the school curriculum is bad.
Students dropping out with large amounts of debt is bad.

And of course there are job interviews, where employers sometimes raise the
 barrier of entry so high that only one in 1000 can pass.


Paying someone more than they are producing is bad. Firing someone is often
expensive and disruptive.


 In OpenStreetMap, people sometimes point to our barriers of entry and
 blindly claim that they must be bad for us. The main page not welcoming
 enough, the editor too difficult, the path to signup too cumbersome, and on
 and on.


If a newbie tries to change something and makes a mess (1), it's only a bad
thing if it's difficult to spot the mistake(2) and revert it (3).

The only important thing is that (2) and (3) must be much easier than (1).
We don't need barriers to entry.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Barriers of Entry

[Serge Wroclawski]

I respectfully disagree with most of your email, comments inline:

On Wed, Sep 14, 2011 at 3:24 AM, Frederik Ramm frede...@remote.org wrote:
 Hi,

 There are barriers of
 entry in the form of entrance exams at places like universities, with the
 aim of assessing the likelihood of someone succeeding in their studies.

I have a bit of contention with this but I'll accept the fact that
there is a correlation between entrance exams and academic success,
but I will rebut this premise later in the mail.

 And
 of course there are job interviews, where employers sometimes raise the
 barrier of entry so high that only one in 1000 can pass.

This is a simple premise that can be rebutted in this context. The
issue of an employer is that of limited resources.

When the resources are large and free, the problems become different.

 Barriers of entry are not always a bad thing; they might keep you and from
 entering a tunnel for which your vehicle is too wide, or they might make it
 less likely for you to spend years at university with little chance to earn
 a degree.

The argument that a university should have entrance exams to keep
people out in order to prevent them from failing out has firstly, a
misunderstanding of the education system, and a misunderstanding of
education in general.

For discussions of universities, I can only speak about the US. In the
US, institutions do have cutoffs for entrance, and will drop the
students they don't feel would make the cut, but they do not then
automatically take the top N highest percent. What they do instead is
to look for a wide diversity in the students, with the intent that a
university provides oppotunity to a great number of students, and the
understanding that diversity builds
strength.

Maybe this is different in Europe, but in the US, this is how things are.

Now I want to address testing in general, and why testing itself is
flawed, especially in how it relates to OSM (since this is where the
mail ultimately leads.

The purpose of education is to educate, and to build citizens, not
merely blast knowledge out and see who catches it. This is why we are
seeing programs which test different teaching methods, which show that
through different ways of approaching the material, we see different
results. Studies are showing that by using some teaching methods,
those students who did poorly previously now excel.

Knowing this to be true, educators can reform the curriculum to be
effective to different groups.  How this relates to OSM later on in
the mail.

 In OpenStreetMap, people sometimes point to our barriers of entry and
 blindly claim that they must be bad for us. The main page not welcoming
 enough, the editor too difficult, the path to signup too cumbersome, and on
 and on.

Some barriers to entry are not barriers to entry, but just barriers.
Using your analogy of a school, if we have a school where all students
walk to school, perhaps we should not place this school on the top of
a mountain.

Similarly if the front page is unfriendly, we should not say Ah, well
that's the cost you pay for trying to use OSM, but rather work with
people to fix it.

 Now some of this might be true and I don't want to keep people from
 improving the overall OSM user experience.

This seems like you know your argument is faulty and reacting accordingly.

 However one has to keep in mind that what we're doing here is, and will
 always be, more complex than, say, taking your dog for a walk.

It depends on the task. Let's take the example of not walking your
dog, but baking a cake.

If I said to you Bake a cake, you could perhaps do it. It might
require some instruction, but chances are you could do it.

Now let's say that you had to start from scratch. That means you need
to grow your own wheat, mill it, raise your own chickens, harvest and
process the sugar, etc. Baking a cake is hard!

But we don't do that. We simplify parts of the task which aren't
essential to the task itself.

And some people even use cake mix, further reducing the work required
in baking a cake.

Some geographic tasks are hard, but we can simplify them to the
components that people need to focus on, and make them easy.

Examples can be provided upon request.



 For OpenStreetMap, we don't gain anything from making it look like
 participating in OSM was the easiest thing in the world. You have to possess
 some skills, and you have to be willing to engage with other people, or else
 your contribution is unlikely to be pleasant for you or the project.

I feel like this is a reaction to something that you're not pointing
out except in the abstract.

Who will argue against community involvement? Not me. But I may say
that not every OSMer needs to be participating on the tagging list,
and can safely use the builtins in their editor.


 Taking
 part in OpenStreetMap requires more sophistication than, say, tweeting about
 where you're having dinner.

I think a Foursquare-type app would be very useful. It would give us

Re: [OSM-talk] Barriers of Entry

[Frederik Ramm]

Hi,

On 09/14/2011 08:07 PM, Serge Wroclawski wrote:

I'm concerned about uneducated newbies messing up OSM, so we need
ways to prevent that.


Hm, not really.

My post was actually aiming at those who *without further thinking* 
claim that tearing down barriers was always a good thing.


If you thoroughly analyze the situation and come to the conclusion that 
there's a group of people who have the means, the brains, and the 
willingness to make a valuable contribution but there's a certain 
barrier that keeps them from doing so, then of course it is good to 
remove that barrier.


(And of course, as someone else said, removing the barrier could also 
mean leaving the barrier itself in place but giving people the help or 
information they need to cross it.)


What I was mainly arguing against is the idea that everyone can make a 
positive contribution if only we get them to (a) learn of OSM, (b) sign 
up and (c) fire up Potlatch or JOSM. There are many people who will not 
be able to make a contribution even then, and even if we give them your 
videos and a nice Potlatch tutorial. And it is *better* to provide 
adequate information upfront, so that these people decide for themselves 
that OSM is maybe not for them, than to lure them into OSM with promises 
of simplicity that evaporate as soon as they click the mouse.


All I'm asking for is for the project to present itself honestly; to 
announce on the packaging what you find inside.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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

Re: [OSM-talk] Barriers of Entry

[ce-test, qualified testing bv - Gert Gremmen]

+1 Serge

I do not think that the experts (read : experienced) OSM such
as Frederik, SteveC and many others  including myself have the skills to 
actually fine tune
OSM to new users. We know too much details, are too involved
and probably too worried about misuse, data soup (yes me too)
and too caring about our data.
(That mechanism is also debit to the License problems and
the troubles around it: other topic)

Regarding the quality of data, I suggest strongly that
a number of different software editors get developed, each targeted to 
a specific data source (or user classifying himself as so).

A bar/café/restaurant POI editor - yes as simple as that-
allowing people that recently visited a restaurant, are a restaurant owner
 or just live in front of it to enter it accordingly to the map.
Approximate place, name and type of food is something
that almost anyone can do, no entry barrier required.

These new users probably are not interested in all OSM tagging subtleties, but
there first successful entrance of a POI will trigger more to come
, and possibly the interest in OSM and ultimately the fine
art of cartography (other editors.)

Furthermore I believe that some heuristic software (server side?) should monitor
edits for probability. An entire block of streets shifting for more
then 100 meters is such an unlikely wanted edit. So is a road crossing
another road of the same type (without node!). Such software would capture
a lot of edit mistakes.
Ultimately it should be such intelligent software that a
user actually needs a lot of OSM skills to be able to
actually create data soup.

I am not sure yet on what to do with such edits when
detected yet, but what the heck, we are thousands to find a solution


Gert


-Oorspronkelijk bericht-
Van: Serge Wroclawski [mailto:emac...@gmail.com] 
Verzonden: woensdag 14 september 2011 20:08
Aan: Frederik Ramm
CC: Talk Openstreetmap
Onderwerp: Re: [OSM-talk] Barriers of Entry

I respectfully disagree with most of your email, comments inline:

On Wed, Sep 14, 2011 at 3:24 AM, Frederik Ramm frede...@remote.org wrote:
 Hi,

 There are barriers of
 entry in the form of entrance exams at places like universities, with the
 aim of assessing the likelihood of someone succeeding in their studies.

I have a bit of contention with this but I'll accept the fact that
there is a correlation between entrance exams and academic success,
but I will rebut this premise later in the mail.

 And
 of course there are job interviews, where employers sometimes raise the
 barrier of entry so high that only one in 1000 can pass.

This is a simple premise that can be rebutted in this context. The
issue of an employer is that of limited resources.

When the resources are large and free, the problems become different.

 Barriers of entry are not always a bad thing; they might keep you and from
 entering a tunnel for which your vehicle is too wide, or they might make it
 less likely for you to spend years at university with little chance to earn
 a degree.

The argument that a university should have entrance exams to keep
people out in order to prevent them from failing out has firstly, a
misunderstanding of the education system, and a misunderstanding of
education in general.

For discussions of universities, I can only speak about the US. In the
US, institutions do have cutoffs for entrance, and will drop the
students they don't feel would make the cut, but they do not then
automatically take the top N highest percent. What they do instead is
to look for a wide diversity in the students, with the intent that a
university provides oppotunity to a great number of students, and the
understanding that diversity builds
strength.

Maybe this is different in Europe, but in the US, this is how things are.

Now I want to address testing in general, and why testing itself is
flawed, especially in how it relates to OSM (since this is where the
mail ultimately leads.

The purpose of education is to educate, and to build citizens, not
merely blast knowledge out and see who catches it. This is why we are
seeing programs which test different teaching methods, which show that
through different ways of approaching the material, we see different
results. Studies are showing that by using some teaching methods,
those students who did poorly previously now excel.

Knowing this to be true, educators can reform the curriculum to be
effective to different groups.  How this relates to OSM later on in
the mail.

 In OpenStreetMap, people sometimes point to our barriers of entry and
 blindly claim that they must be bad for us. The main page not welcoming
 enough, the editor too difficult, the path to signup too cumbersome, and on
 and on.

Some barriers to entry are not barriers to entry, but just barriers.
Using your analogy of a school, if we have a school where all students
walk to school, perhaps we should not place this school on the top of
a mountain.

Similarly if the front page is unfriendly, we 

Re: [OSM-talk] Barriers of Entry

[Ian Sergeant]

Gert Gremmen g.grem...@cetest.nl wrote on 15/09/2011 04:43:43 AM:
 
 I am not sure yet on what to do with such edits when
 detected yet, but what the heck, we are thousands to find a solution

Sounds like a problem that may be solved by some kind of graduated access 
scheme.

Anyone can sign up and add a POI to the map, or add information to an 
existing object (add an address, add a bus stop, bakery, or oneway 
annotation).

At the next grade threshold, you can alter existing information. (change a 
way type, change a oneway annotation, etc).

At the next grade threshold, you can free to move, delete, etc.

Throw in a close link to openstreetbugs, so people can report what they 
can't change.

No protection against the malicious user intent on doing damage and with 
time on their hands, but it is a way of allowing access to the easy stuff 
to all, and everything to those prepared to spend a little time to 
understand what is involved.

If the API enforces the policy, then front end editors can deal with it as 
they will, and the oneway competition, or address quiz are still 
possibilities.

Of course how people progress to the next grade would be an interesting 
system to devise.  Perhaps a multiple choice quiz comparing wiki voting to 
tagwatch? :-)

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

Re: [OSM-talk] Barriers of Entry

[Jaakko Helleranta.com]

I very much like Ian's idea. Coincidentally I talked about this with some 
people at SotM.

It seems to me that a number of people have started editing osm after a 
significant delay because they've felt the barriers badly (both regarding tools 
and technical creation of the map as well as fear of breaking the data). I 
remember these fears / issues being one cause for my delayed start to 
contributing to osm.

Now, what if we had a more or less obviously optional (opt-out) graduated 
access scheme?

What if we simply required the promise of users to say that I know how to edit 
this  that feature, Sure I understand what tertiary roads are over 
unclassified/residential -- and I promise not to tag all roads I edit with 
tertiary!, I'll definitely look into empty nodes history before deleting them 
to make sure that no one has deleted the tags by accident, or Of course I 
won't mess up the coastline. Etc.

What if we simply trusted that people can recognize when they are able to do 
certain types of more difficult edits?

There could also be an I'd love it if someone more experienced (or 
self-confident) could double check that my edits are ok before they get 
submitted to the live database! option.

Since there were multiple people at SotM who think they would have started 
editing sooner than they ended up doing I'm wondering how many people there r 
out there that have signed up but have never made an edit that could already 
have made edits if we would have such options in place? I'm also pretty 
confident that such options, even when set to be voluntary, could reduce some 
common quality problems. 

Cheers from Haiti (which I think would benefit from some of the above mentioned 
options),
jaakkoh

Sent from my BlackBerry® device from Digicel
--
Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta

-Original Message-
From: Ian Sergeant iserg...@hih.com.au
Date: Thu, 15 Sep 2011 09:02:08 
To: ce-test, qualified testing bv - Gert Gremmeng.grem...@cetest.nl
Cc: Talk Openstreetmaptalk@openstreetmap.org
Subject: Re: [OSM-talk] Barriers of Entry

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

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

Re: [OSM-talk] SOTM streaming!

[Toby Murray]

I just made one more pass through my uploads and cleared out some junk
where the wireless network ate my broadcast during the HOT
presentation. I haven't watched all of the videos myself but I will
say the quality varies a lot depending on the network connection,
where I was sitting in the room, etc. So don't expect miracles. But
there are definitely some watchable sessions. Any sessions where the
fosslc videos have been uploaded will have much better audio and a
better view of the slides but no view of the stage/presenter. I assume
more of these will be coming in the next week.

I just linked all of my videos on the SOTM 2011 wiki page:
http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2011

Enjoy! As for the parts that aren't good enough to be enjoyable...
well... you should have come to SOTM in person!  :)

Toby


On Sun, Sep 11, 2011 at 10:45 AM, Toby Murray toby.mur...@gmail.com wrote:
 I went through last night and reworked the video names and
 descriptions on the recorded videos a bit. Some of them had default
 descriptions and such. I think I am going to set a 3G data usage
 record this month. :)

 Yay for unlimited plans.

 Toby

 On Fri, Sep 9, 2011 at 10:47 AM, Toby Murray toby.mur...@gmail.com wrote:
 So I brought a webcam to SOTM. I am broadcasting on ustream. Unfortunately
 my poor netbook doesn't have the CPU to do things very well so the video is
 kind of worthless but I hear the audio is good. And there are ads. But if
 you want to follow along...

 http://www.ustream.tv/channel/KSUToebee

 Toby


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

Re: [OSM-talk] Barriers of Entry

[ce-test, qualified testing bv - Gert Gremmen]

I definitely do NOT want a *diploma* system
with less or more approved users.. N

We don't want OSM to change into Brave New World,
1984 or distinct between users on other characteristics
History is full of such mistakes.
If a novice wants to start with JOSM , so be it, but we want
him to be attracted to something he understands right now
and prefer that before understanding the power of a real
editor.



We just need a large set of tools (editors)
that automatically attract the right user level.

And add to that a set of heuristic control measures 
in software that refuse / flag / conditionally approve 
edits made by stupidity / mouse errors / vandalism  / ignorance.



-Oorspronkelijk bericht-
Van: Jaakko Helleranta.com [mailto:jaa...@helleranta.com] 
Verzonden: donderdag 15 september 2011 4:34
Aan: Ian Sergeant; ce-test, qualified testing bv - Gert Gremmen
CC: Talk@OSM
Onderwerp: Re: [OSM-talk] Barriers of Entry

I very much like Ian's idea. Coincidentally I talked about this with
some people at SotM.

It seems to me that a number of people have started editing osm after a
significant delay because they've felt the barriers badly (both
regarding tools and technical creation of the map as well as fear of
breaking the data). I remember these fears / issues being one cause for
my delayed start to contributing to osm.

Now, what if we had a more or less obviously optional (opt-out)
graduated access scheme?

What if we simply required the promise of users to say that I know how
to edit this  that feature, Sure I understand what tertiary roads are
over unclassified/residential -- and I promise not to tag all roads I
edit with tertiary!, I'll definitely look into empty nodes history
before deleting them to make sure that no one has deleted the tags by
accident, or Of course I won't mess up the coastline. Etc.

What if we simply trusted that people can recognize when they are able
to do certain types of more difficult edits?

There could also be an I'd love it if someone more experienced (or
self-confident) could double check that my edits are ok before they get
submitted to the live database! option.

Since there were multiple people at SotM who think they would have
started editing sooner than they ended up doing I'm wondering how many
people there r out there that have signed up but have never made an edit
that could already have made edits if we would have such options in
place? I'm also pretty confident that such options, even when set to be
voluntary, could reduce some common quality problems. 

Cheers from Haiti (which I think would benefit from some of the above
mentioned options),
jaakkoh

Sent from my BlackBerry(r) device from Digicel
--
Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta

-Original Message-
From: Ian Sergeant iserg...@hih.com.au
Date: Thu, 15 Sep 2011 09:02:08 
To: ce-test, qualified testing bv - Gert Gremmeng.grem...@cetest.nl
Cc: Talk Openstreetmaptalk@openstreetmap.org
Subject: Re: [OSM-talk] Barriers of Entry

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


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

[OSM-talk-nl] Fwd: Gedeelte binnenstad Zutphen verdwenen

[Martijn van Exel]

Wat ik kan doen is doorsturen naar talk-nl, bij deze. Vanuit gmail, btw ;)

Martijn


-- Forwarded message --
From: Steven Wartena steven.wart...@gmail.com
Date: 2011/9/14
Subject: Gedeelte binnenstad Zutphen verdwenen
To: m...@rtijn.org


Hallo Martijn,

Ik stuur je rechtstreeks een mail omdat ik net Gmail niet naar talk-nl
kan mailen.

Het volgende wil ik meedelen.

Ik map zo nu en dan in Zutphen en omgeving. Na het mappen kijk ik na
een tijdje periodiek bij Keep-Right om te zien of er fouten gemaakt
zijn. Vandaag keek ik weer en zag dat een groot gedeelte van de
binnenstad van Zutphen verdwenen is. Niet alleen straten en paden, ook
gebouwen zijn verdwenen.
Kan iemand dit terug zetten vanuit een bckup.

http://keepright.ipax.at/report_map.php?zoom=14lat=52.13464lon=6.20488layers=B00Tch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C313%2C350%2C380show_ign=1show_tmpign=1

groet,
S






-- 
martijn van exel
schaaltreinen.nl

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

Re: [OSM-talk-nl] Fwd: Gedeelte binnenstad Zutphen verdwenen

[Cartinus]

Hallo,

Ik heb de enige changeset van de volgende user teruggedraaid. Ik hoop dat dat 
alles oplost.

http://www.openstreetmap.org/user/H%20Janson/edits

 -- Forwarded message --
 From: Steven Wartena steven.wart...@gmail.com
 Date: 2011/9/14
 Subject: Gedeelte binnenstad Zutphen verdwenen
 To: m...@rtijn.org


 Hallo Martijn,

 Ik stuur je rechtstreeks een mail omdat ik net Gmail niet naar talk-nl
 kan mailen.

 Het volgende wil ik meedelen.

 Ik map zo nu en dan in Zutphen en omgeving. Na het mappen kijk ik na
 een tijdje periodiek bij Keep-Right om te zien of er fouten gemaakt
 zijn. Vandaag keek ik weer en zag dat een groot gedeelte van de
 binnenstad van Zutphen verdwenen is. Niet alleen straten en paden, ook
 gebouwen zijn verdwenen.
 Kan iemand dit terug zetten vanuit een bckup.

 http://keepright.ipax.at/report_map.php?zoom=14lat=52.13464lon=6.20488la
yers=B00Tch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2
C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202
%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C2
82%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C313%2C350%2C380show_ign=1sh
ow_tmpign=1

 groet,
 S



-- 
m.v.g.,
Cartinus

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

Re: [talk-au] Missing streets in Sydney

[Ian Sergeant]

On 6 September 2011 19:33, Andrew Harvey andrew.harv...@gmail.com wrote:


 With the use of source tags you won't have to, you can filter out
 anything without source=survey leaving you with a map with just
 surveyed data (in theory). You filtering out data you don't like is a
 much better option than forcing everyone else to not have access to
 that data just because you don't like it. (I'm thinking of the case
 where you have some area/features that no one is currently mapping by
 local_knowledge, and some kind soul helps out by tracing the
 area/feature that no one else has added from a ground survey yet).

 (but this will omit stuff which was originally traced, but then
 confirmed via survey without the need to update the source tags as
 nothing was updated)



Had a bit of a look into this..

Of all the ways in Australia, less than 50% have source tag for how the
location/name information was derived.

Of those that do, around half indicate some form of imagery was used as the
source (it seems that we are a country of tracers :-).

Interestingly enough, around a quarter of ways traced from imagery are
named, with no source tag indicating of how the name of the way was derived,
could you say that at least some of these have been surveyed without being
tagged accordingly?  Or could you even think something more sinister?

My conclusion - there is no way I can see in Australia to reliably construct
a surveyed or traced data-set based on the tagged source information as it
now exists.

Ian.
___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-br] Novo site do Mapas Livres

[Joop Kiefte]

Eu testei um pouco, e achei alguns problemas:

   - Lugares fora do Brasil não parecem funcionar.
   - Redações de mais de uma semana ainda não aparecem.


Em terça-feira, 13 de setembro de 2011, vitor escreveu:

 Oi Djavan,

 Obrigado, deu um trabalho, apesar de simples.

 Vamos divulgar bastante, para as pessoas conhecerem mais e melhorarem o
 mapa.

 O site usa somente tecnologias open source, o leaflet e jquery,
 especificamente.

 Eu não publiquei o source ainda, mas se alguém manjar de Javascript bem e
 quiser colaborar, é só entrar em contato.

 Eu também gostaria de substituir o sistema do ajuda.mapaslivres.org pelo
 OSQA (http://osqa.net), sem alguém quiser se aventurar.

 Abraços,
 Vitor



 2011/9/13 Djavan Fagundes dja...@comum.org javascript:_e({}, 'cvml',
 'dja...@comum.org');


 Só pra parabenizar pelo novo site, que ficou ótimo.

 É um esquema deste que eu tinha pensado pra gente fazer no domínio
 osm-br.org

 http://www.mapaslivres.org/

 PS: Os fontes são livres? tenho como baixar?

 --
 Djavan Fagundes

 E-mail | xmpp: dja...@comum.org javascript:_e({}, 'cvml',
 'dja...@comum.org');

 http://djavan.comum.org/blog/
 http://butequeiro.comum.org/
 http://comum.org



 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org javascript:_e({}, 'cvml',
 'Talk-br@openstreetmap.org');
 http://lists.openstreetmap.org/listinfo/talk-br



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

Re: [Talk-de] landuse = highway

[Garry]

Am 13.09.2011 19:45, schrieb Henning Scholland:
landuse=highway oder road sagt doch aus, dass die Fläche als Straße 
genutzt wird. Das ist auch bei nicht zugänglichen Ohren nicht der 
Fall. Wenn das Land dort nicht genutzt wird, dann sollte man das auch 
so erfassen.


Die Strasse hört doch nicht am Fahrbahnrand auf.
Bei Strassenneubauten werden die Ohren heutzutage häufig als 
Versickerungsbecken für das Regenwasser das von der Fahrbahn abgeleitet 
wird,
gehört dann also auch als Entwässerungsanlage zur Strasse dazu. 
Ansonsten werden die Ohren häufig für betriebliche Zwecke (z.B. Lagerung 
von Betongleitwänden) verwendet. Wenn also keine explizit anderwertige 
Nutzung vorliegt sehe ich keinen Grund die Ohrflächen von landuse=road 
auszuschliessen.



Garry

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

Re: [Talk-de] Datenhaltung: Flächen und Flächen_grenzen_

[Martin Koppenhoefer]

Am 14. September 2011 00:28 schrieb Christian Müller cmu...@gmx.de:
 Am 12.09.2011 19:47, schrieb Martin Koppenhoefer:

 place-polygon heisst nicht, dass dieses Polygon unbedingt durch einen
 doppelten Way gemappt werden muss, Multipolygone rechne ich da
 natürlich auch dazu.

 Dann hätten wir theoretisch einen Konsens.  Theoretisch deshalb, weil der
 way eines landuse=* geschlossen sein muss.  Man korrigiere mich, wenn das
 nicht zwingend notwendig ist.  Bisher ist es in Validatoren zumindest eine
 Warnung, wenn ein nicht geschlossener way mit Flächen-Tags (landuse)
 versehen ist.  Wenn diese Warnung ignoriert werden kann, haben wir auch
 praktisch einen Konsens.


Die Warnung kommt doch nur, wenn man die einzelnen ways taggt. Wenn
die tags dort sind, wo sie hingehören (Relation) gibt es AFAIK auch
keine Warnung.

Gruß Martin

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

[Talk-de] OT: Petition gegen Vorratsdatenspeicherung

[Frank Sautter]

Hallo zusammen,

das ist OffTopic, aber ich denke den Meisten die bei OpenStreetMap 
mitmachen ist klar, was man mit gesammelten Daten so alles machen kann.


Stand jetzt benötigt die Petition bis

   heute Nacht 14.09.2011 24:00 Uhr

noch rund 5.500 Mitzeichner, damit Kai-Uwe Steffens die Petition 
persönlich im Bundestag vortragen kann.


Die allgemeine Zeichnungsfrist endet am 06.10.2011

http://zeichnemit.de/

Frank

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

Re: [Talk-de] Nominatim

[bkmap]

Am 13.09.2011 21:27, schrieb Dimitri Junker:

Hallo,



Das stand doch genau da?!1elf



Ups, da sah für mich nichts nach Ortsname aus, sorry.


Erstes wird gefunden, zweite nicht.



Ich habe einen Bugreport erstellt


Danke, hätte ich jetzt auch gemacht.

Gruß
Burkhard




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

Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]

[Georg Feddern]

Moin,

Christian Müller schrieb:

Am 13.09.2011 17:14, schrieb Martin Koppenhoefer:

ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als
landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund
des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor.


welchen Sinn soll das haben?  so kommen wir nicht weiter..



Seit wann muss ein Hobby einen Sinn haben? ;-) 

Die Granularität von landuse=*  ist in OSM einfach nicht die von 
building=*  und wenn sie das wäre, wäre landuse=*  für die meisten 
Datennutzer useless=*




Ich glaube kaum, dass Martin ein landuse-Polygon in den Grenzen des 
buildings 'malt'.
Und auf dem Wohn-Grundstück finden sich evtl. Bäume - aber da haben die 
Forstarbeiter bestimmt keinen Zugriff drauf!



Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen
wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das
weder fordern noch pauschal ausschließen wollen.


Ja, können sie ja machen - haben wir die Ressourcen?  Macht das in OSM 
Sinn?
Ich denke nicht, wir sollten bei dem 'vorrangig' in der Definition zur 
Bodennutzung bleiben.


Schon wieder diese Sinn-Frage ...
'Wir' haben auch kaum übergreifend im ländlichen Raum die Resourcen, 
überhaupt landuses zu erfassen - sollen 'wir' das deshalb von vornherein 
lassen?
Äußerst vorrangig besteht die Erdoberfläche aus Wasser - das spart 
unheimlich Resourcen!

Noch(!) besteht Deutschland 'vorrangig' aus Landwirtschaftsfläche ...
In meinem Dorf überwiegt eindeutig die residential-Nutzung - muss ich 
deshalb die trotzdem das Gesamterscheinungsbild prägenden 
Vollerwerbsbauernhöfe unterschlagen?
Auf dem Grundstück im Wald steht definitiv kein 'forrest' - aber ich 
darf diese Besonderheit der Einzel-Streu-Besiedelung einer Gegend nicht 
erfassen, weil es jemandem nicht genehm ist?
Ich bin hier die Resource vor Ort - und da nehme ich mir das Recht 
heraus, zu entscheiden, wofür ich diese Resource verschwende! ;-)
Und ja, es macht Sinn für mich, wenn ich auf meiner kleinen 
großformatigen Karte das private Grundstück vom öffentlich zugänglichen 
Wald unterscheiden möchte.


Ich denke nicht, dass diese Granularitätsebene, auf der die Ämter 
mappen für eine OSM-Definition von landuse=* geeignet ist.  Natürlich 
gibt's kein Verbot, diese Granularität in OSM zu benutzen, aber uns 
geht es hier um eine brauchbare Wiki-Definition, die würde ich nicht 
strikt gestalten.


'vorrangige', reale Flächennutzung


Das ist durchaus eine sinnvolle, nicht-strikte Definition.
Aber warum erwartest Du dann, das man sich _strikt_ an eine nicht näher 
angegebene Größenordnung hält?

Wo muss man diese Größenordnung ziehen?

Du musst auch mal überlegen, welche Konsquenzen das hätte:  landuse=*  
würde evtl. nur noch auf dem letzten Zoomlevel renderbar sein, auf 
allen anderen gibt's ein verrauschtes  noise bitmap.


Nein, dass wären 'falsche' Renderregeln.
Die Granularität bestimmt die Breite der definierten landuses. (Leider 
wird/wurde bei OSM oft zu schnell in die Breite gegangen, statt zu 
staffeln. :-( )
Erstens endet die landuse-Granularität z. Z. spätestens an der 
Grundstücksgrenze - den so sinnlosen landuse=grass mal außen vorgelassen 
- und gleiche Nutzungen nebeneinander ergeben eine gemeinsame Fläche, im 
Zweifelsfall den von Martin angesprochenen Block (zwischen 
Verkehrswegen) - den man ja nicht auf Krampf unterteilen muss. Aber 
setzt sich der landuse=road durch, ist dort dann sowieso Schluss, falls 
sich der Schwebe-Ansatz nicht durchsetzt.
Und zweitens werden ab einem gewissen Zoomlevel landuses rendermäßig 
zusammengefasst (landwirtschaftlich, bebaut/besiedelt) sowie kleine 
Flächen weggelassen.
Und wenn dort kein Pixel für den Verkehrsweg mehr bleibt (= 
weggelassen) ergibt sich auch dort grafisch eine durchgehende Fläche.


Wenn die Flächennutzung auf der Granularitätsebene von Baufenstern 
(oder nahe diesen) arbeitet, hätten wir zum Schluss 25*Anzahl der 
building Polygone an Daten in der Stadt (für jedes Gebäude finde ich 
unter Garantie 25 verschiedene Bodennutzungsarten ringsum).


Hier hätte ich gerne Belege für (diese Übertreibung) ...


  Das ist für landuse=*, useless=*..


Allerdings - aber in meinen Augen eben auch nicht zwangsläufig zu 
befürchten.
Insbesondere nicht, wenn man sinnvoll staffeln würde, statt weiter nur 
(oft unüberlegt) in die Breite zu gehen.




Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels 
multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' 
Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag 
aufmachen, um landuse micromapping zu betreiben..
Denn landuse micromapping erhöht Eintrittsbarrieren, anstatt sie zu 
senken.


Sehe ich - mittlerweile - anders. Multipolygone oder riesige Flächen 
schrecken da eher ab, nach meiner bisherigen Erfahrung.



diese Einheiten macht (bis zu Flächen, die keine Straßen mehr
beinhalten, einzelne Blumenbeete meine ich damit nicht), um so
einfacher wird es für die folgenden 

Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Fl

[Martin Koppenhoefer]

Am 14. September 2011 00:51 schrieb Christian Müller cmu...@gmx.de:
 Am 13.09.2011 13:20, schrieb Martin Koppenhoefer:
 Am 13. September 2011 07:01 schrieb Rainer Klugerklug...@web.de:
 +1 in allen Punkten.  Kleine Korrektur, für Grenzen wird
    - auf dem /way/  border=*


es gibt weltweit insgesamt 196 mal border in der Datenbank. Sind die
alle von Dir?


    - in der /relation/  boundary=*


gem. Taginfo gibt es border_type 43728 mal. Die Werte dafuer sind city
(15073) (bei insgesamt 2 cities in der db), county, town, village
etc. und gem. Wiki ist dieser tag parallel zu place zu nutzen.


 Merken sollte man sich noch, dass

    place als Fläche/area /hier/ bestritten wird (verschiedene Auffassungen),


im Wiki stand von Anfang an ausdruecklich, dass nodes und Flaechen
sinnvoll sind.

Gruss Martin

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

Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]

[Garry]

Am 14.09.2011 03:14, schrieb Christian Müller:

Am 13.09.2011 17:14, schrieb Martin Koppenhoefer:

ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als
landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund
des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor.


welchen Sinn soll das haben?  so kommen wir nicht weiter..
Es ist ein Alleinstellungsmerkmal und erhöht die Auffindbarkeit solcher 
Besonderheiten.
Wenn Du z.B, eine OSM-Garminkarte verwendest in der aus Platzgründen 
keine Häuser dargestellt werden siehst Du an der Stelle
des Hauses nur Wald, ohne eigenem landuse ist so ein Haus dann auf der 
Karte unauffindbar.
Und nein, ich sehe dass nicht als Mappen für den Renderer an sondern ein 
Mappen der Realität zur besseren Nutzubarkeit der Daten.


Die Granularität von landuse=*  ist in OSM einfach nicht die von 
building=*  und wenn sie das wäre, wäre landuse=*  für die meisten 
Datennutzer useless=*
Ich versteh Martin mit das Gebiet zweier dauerhaft bewohnter Häuserso 
dass er die Summe der beiden Grundstücke als eine landuse=residential
Fläche mappen und nicht die Gebäude selbst als einzelne landuse-Flächen 
mappen will.



Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen
wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das
weder fordern noch pauschal ausschließen wollen.


Ja, können sie ja machen - haben wir die Ressourcen?  Macht das in OSM 
Sinn?

In Bezug auf Einzelhäuser im Wald ist das nicht wirklich ein Argument
Ich denke nicht, wir sollten bei dem 'vorrangig' in der Definition zur 
Bodennutzung bleiben.
Bei so einer gravierende Nutzungsänderung wie hier die kleine bewohnte 
Fläche in einem riesigen unbesiedelten Gebiet sollte man schon 
differenzieren...



Beim Taggen von landuse=*  über seine Grenzen, macht aber auch ein 
amtlicher Datenimport keine Probleme.  Man legt das einfach über das, 
was in OSM da ist, taggt die ways des Imports als


border=administrative
source=official

und erstellt Multipolygone mit

type=multipolygon
landuse=xyz
official_key1=*
official_key2=*
official_key3=*
source=official


Ich denke nicht, dass diese Granularitätsebene, auf der die Ämter 
mappen für eine OSM-Definition von landuse=* geeignet ist.  Natürlich 
gibt's kein Verbot, diese Granularität in OSM zu benutzen, aber uns 
geht es hier um eine brauchbare Wiki-Definition, die würde ich nicht 
strikt gestalten.


'vorrangige', reale Flächennutzung

Du musst auch mal überlegen, welche Konsquenzen das hätte:  landuse=*  
würde evtl. nur noch auf dem letzten Zoomlevel renderbar sein, auf 
allen anderen gibt's ein verrauschtes  noise bitmap.   Weiterhin 
hatte sich jemand über die Fülle der Daten in Frankreich durch den 
Import aufgeregt.  Wenn die Flächennutzung auf der Granularitätsebene 
von Baufenstern (oder nahe diesen) arbeitet, hätten wir zum Schluss 
25*Anzahl der building Polygone an Daten in der Stadt (für jedes 
Gebäude finde ich unter Garantie 25 verschiedene Bodennutzungsarten 
ringsum).  Das ist für landuse=*, useless=*..


Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels 
multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' 
Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag 
aufmachen, um landuse micromapping zu betreiben..



Denn landuse micromapping erhöht Eintrittsbarrieren, anstatt sie zu 
senken..






Je kleiner man
diese Einheiten macht (bis zu Flächen, die keine Straßen mehr
beinhalten, einzelne Blumenbeete meine ich damit nicht), um so
einfacher wird es für die folgenden Mapper, dort weiterzuarbeiten.


Irrglaube, denn Du hast dann statt Struktur, rohe Komplexität 
abgebildet.  brute-force, statt elegance.  Es gibt keinen Bezug deiner 
Mini-Flächen untereinander.  Man sieht sprichwörtlich den Wald vor 
lauter Bäumen nicht mehr.  Wenn deine Mini-Einheit was bringen soll, 
dann nur über die Multipolygon-Methode, mittels derer diese 
Mini-Flächen wieder zu groben, fassbaren Flächen gruppiert werden 
können, bis zu dem Punkt, wo man wieder von 'vorrangiger', realer 
Flächennutzung sprechen kann, was landuse=* jetzt ist.



woher kommt eigentlich dieser Wunsch, die Realität in diesem Punkt 
nicht (in unserem Rahmen) möglichst genau abzubilden, sondern grobe 
unfragmentierte Gebiete haben zu wollen? Kann man das nicht durch 
Datenverarbeitung hinterher machen, wenn man gerne vereinfachte 
Geometrien haben will?


Nein, aus dem gleichen Grund, aus dem Du die Erfassung der 
Siedlungsfläche (nach deiner Definition) explizit wünschst.


Um es mal auf dein Beispiel mit der dt. Staatsgrenze zu übertragen:

Die ist auch explizit erfasst, obwohl man sie aus der Summe aller 
nächsttieferen Grenzen berechnen kann.
Und die nächsttieferen Grenzen wiederum aus den nächsttieferen..  
ad absurdum



Der Grund weshalb man das nicht berechnet, ist, neben dem 
Rechenaufwand, dass wir in OSM selbst die Information der Realität 
haben wollen, 

Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)

[Christian Müller]

Am 13.09.2011 18:13, schrieb Martin Koppenhoefer:

Ich verweise nochmals darauf, dass border=administrative  in OSM bereits für
jede Nation ausdifferenziert wird, d.h. border=administrative entsprechen ab
admin_level 3 den innernationalen Verwaltungsgrenzen.  Die kleinste Einheit
bei den Verwaltungsgrenzen in D ist und bleibt die Flurstücksgrenze.  Das
OSM das bisher nicht so abbildet ist ein (ohne größeren Aufwand) lösbares
Problem.

hast Du da eine Quelle dafür?


http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#admin_level
(Ausdifferenzierung in Abh. der Administration)

http://de.wikipedia.org/wiki/Flurstücksgrenze
(Feststellung im Verwaltungsverfahren der Behörden - Verwaltungsgrenze)


http://www.gll.niedersachsen.de/live/live.php?navigation_id=10669article_id=50951_psmand=34
Verwaltungsgrenzen (Administrative Grenzen des 
Liegenschaftskatasters)
Diese Administrativen Grenzen des Liegenschaftskatasters bestehend 
aus Flur-, Gemarkungs-, Gemeinde- und Landkreisgrenzen [...]



http://www.landesvermessung.sachsen.de/inhalt/produkte/lika/alk/alk_detail.html
(Foliendefinitionen betrachten,  Gemarkungs- und Flurgrenzen sind 
keine _politischen_ Grenzen,
Verwaltungsgrenzen hingegen, sprich _administrative_ Grenzen, aber 
schon)




http://de.wikipedia.org/wiki/Kataster#Aufbau_eines_Katasters
Aufgrund der chronologischen Fortschreibung des immerwährend 
aufzubewahrenden Katasters können bei Bedarf Grenz- und 
Vermessungspunkte örtlich aufgesucht und fehlende Vermarkungen oder 
Sicherungen wiederhergestellt werden. Die Verbindung zweier Grenzpunkte 
bildet eine Flurstücksgrenze.


Damit wäre, wenn GPS genau genug arbeiten würde, die Erfassung der 
Flurstücksgrenze in OSM vor Ort durchführbar.  Weil Vermessungspunkte 
vor Ort wiederspiegeln, was im Kataster steht und vice versa.  Wenn man 
erkennen könnte, welche Grenzpunkte an einer Gemarkungsgrenze, bzw. 
Wohngebietsgrenze teilnehmen, könnten man damit /praktisch/ auch amtl. 
Grenzen /in/ der Realität exakt erfassen - nur lassen sich eben mit 
unseren GPS-Receivern keine Grenzsteine vermessen..  Evtl. taugt aber 
ein gut aufgelöstes Luftbild im Zshg. mit Information, die man vor Ort 
gesammelt hat..





PS:  Bitte nicht immer border schreiben, es heisst boundary.


Ich spreche von der basisgeometrischen Grenze, dem mit 'border=*' 
getaggten way, der in OSM Grundlage von boundary-Relationen ist.


http://en.wikipedia.org/wiki/Border
borders define /geographic/ boundaries


Es gibt auch boundaries, die nicht-geografisch sind, die betrachten 
wir hier aber nicht.



Gruß


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

Re: [Talk-de] landuse - gewerbliche Flächen

[Christian Müller]

Am 13.09.2011 18:17, schrieb Martin Koppenhoefer:

+1, hört sich vernünftig an. Ob es Hotels oder Restaurants (oder
beides) sind, ergibt sich ja aus den POIs.
man könnte übrigens auch einfach zusätzlich landuse:ISIC=H taggen
(wenn es Sinn machen sollte, diese ISIC als Grundlage anzuerkennen).


+1  Dann aber wirklich nur zusätzlich, sonst lassen sich ohne den 
Standard die Daten nicht mehr interpretieren.  Einen Standard zu nutzen, 
ist besser, als sich von ihn abhängig zu machen..


Wenn für eine Fläche möglich, kann so die Einordnung in weitere 
Standards angeben werden, ohne human readable kaputt zu machen..


landuse=commercial
commercial=hospitality
landuse:ISIC=H
landuse:SIC=...


SIC ist ein Pendant zur ISIC (UNO / EU).  Schätzungsweise ist ISIC ein 
superset von SIC  (keine Garantie auf die Aussage).


http://en.wikipedia.org/wiki/Standard_Industrial_Classification



Ich würde aber die SIC nicht als Basis für eine Kompatibilitätssuche zu 
landuse=* nutzen, da sie wesentlich strukturierter/umfassender zu sein 
scheint, und zudem kein internationaler Standard ist.  Das ist was für 
später, wenn die Datenlage in OSM so gut ist, dass sich Mapper langweilen.




Gruß


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

Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued

[Christian Müller]

Am 13.09.2011 17:58, schrieb Martin Koppenhoefer:

Du bist mit siedlungsgeographischen Daten nicht falsch, genauso wie admin.
Grenzen nicht falsch sind.  Beide können in OSM koexistieren, sofern man
in der Lage ist, sie auseinanderzuhalten.  Wenn admin. Grenzen mit
historischen oder siedlungsgeographischen, die durch die Flächennutzung
bestimmt werden, vermanscht werden, dann freilich nicht.

Ganz genau. Du warst es, der im Wiki bei place das Gegenteil
geschrieben hat, schon vergessen?


;-)  Ich habe das Zusammengemansche von

place node als amtl. admin_centre
border=administrative
und border=landuse  (i.e. Siedlungsflächengrenze)

gelöst, indem ich den place node, den bestehenden best practices dieser 
Wiki-Seite folgend,  /weg/ von einem ominösen place polygon gerückt 
habe.  Du siehst an diesem Sachverhalt, dass sowohl als auch


place in Relation zur Verwaltungsgrenze
place in Relation zur Siedlungsflächengrenze

steht.  Der /Ortsname/  ist so unscharf, dass er durch keine Grenze 
eindeutig besetzt wird, weder durch die Siedlungsflächengrenze, noch 
durch die Verwaltungsgrenze.  Denn man versteht _beides_ darunter. Warum 
sollte es eine Gewichtung geben, indem man place=* als Siedlungsfläche 
wiederverwendet?  Diese Gewichtung gibt es in der Realität nicht, sie 
ist gar nicht quantifizierbar.  Genau deshalb sollte man dafür sein, den 
POI-Charakter von place=* zu erhalten.


Man kann festhalten:

/Ein/ Ortsname steht in Bezug zu /mindestens/ einer Grenze.
/Mehrere/ Ortsgrenzen, auch unscharfe, können /ein und demselben/ 
Ortsnamen zugeordnet sein.


(Es gibt auch gleiche Ortsnamen an geografisch völlig 
unterschiedlichen Orten..  Das ist hier nicht gemeint)




Das ich kein Einzelfall bin, der das so sieht, zeigt Dir wieder einmal, 
u.a., Wikipedia


http://de.wikipedia.org/wiki/Ortsgrenze

- Es wird /nicht/ nur die Siedlungsflächengrenze als Ortsgrenze 
verstanden,  /auch/, aber nicht nur.



http://de.wikipedia.org/wiki/Toponomastik  klärt unser Missverständnis auf

Die Seite schreibt, dass im deutschen  'Ortsname' doppelt verwendet wird,

- zum einen als Synonym für Toponym  (und genau dort sehe ich 
place=* angesiedelt)
- zum anderen ///im Speziellen/// als Name einer Siedlungsstelle 
(dort siehst Du place=* offenbar)


Letzteres grenzt zigtausende bisherige Verwendungen von place=* aus. 
place ist in OSM _nicht_ nur eine Siedlungsstelle.  Auch, aber eben 
nicht nur.  place values erfassen Toponyme in Größenordnungen von 
Kontinenten bis runter zu Waldlichtungen.  Da ist keine Systematik 
erkennbar, bis auf eben den Fakt, dass es Toponyme erfasst.




Du kannst helfen, die Unterscheidbarkeit zu verbessern, indem Du die 
Siedlungsfläche (egal ob nach deiner oder meiner Lesart) nicht mit 
place=* vermischen würdest..  Vielleicht als


type=multipolygon
boundary=settlement

mit /ways/  border=landuse   als Mitglieder..



Gruß
Christian


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

Re: [Talk-de] landuse - gewerbliche Flächen - ISIC im Web

[Christian Müller]

Die Wikipedia-Seite zur ISIC enthält nur die obere Ebene der ISIC,
hier gibt es mehr Infos, wenn das näher interessiert:

http://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=27


Kulturelle Sachen, Erholung und Unterhaltung werden dort unter Kategorie 
R geführt - sind also in diesem Standard auf der Top-Ebene von 
restlicher Industrie unterschieden.


Für OSM würde ich, wenn man dazu reale Flächennutzung erfassen will, 
aber nur Theater- und/oder Musikerviertel mappen - wenn sich 
Kulturbetriebe in größeren Städten in einem Gebiet konzentrieren.


Das einzelne Kleinkunsttheater rechtfertigt m.E. noch nicht die 
'vorrangige' Flächennutzung zu ändern.  Da reicht die Erfassung auf 
tieferer Ebene durch amenity=..


Wenn das Kulturviertel auch zum Wohnen 'bedeutend' genutzt wird, evtl.
landuse=residential;cultural  oder
landuse=residential;arts

(Mischgebiet im OSM Sinne)



Gruß


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

[Talk-de] Ortsteil-Geometrien Berlin jetzt unter CC BY erhältlich

[Alexrk]

http://daten.berlin.de/datensaetze/ortsteil-geometrien-berlin

Alex

--
http://de.wikipedia.org/wiki/Benutzer:Alexrk2



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

Re: [Talk-de] Datenhaltung: Flächen und Flächen_grenzen_

[Christian Müller]

Am 14.09.2011 08:52, schrieb Martin Koppenhoefer:

Am 14. September 2011 00:28 schrieb Christian Müllercmu...@gmx.de:

Am 12.09.2011 19:47, schrieb Martin Koppenhoefer:

place-polygon heisst nicht, dass dieses Polygon unbedingt durch einen
doppelten Way gemappt werden muss, Multipolygone rechne ich da
natürlich auch dazu.

Dann hätten wir theoretisch einen Konsens.  Theoretisch deshalb, weil der
way eines landuse=* geschlossen sein muss.  Man korrigiere mich, wenn das
nicht zwingend notwendig ist.  Bisher ist es in Validatoren zumindest eine
Warnung, wenn ein nicht geschlossener way mit Flächen-Tags (landuse)
versehen ist.  Wenn diese Warnung ignoriert werden kann, haben wir auch
praktisch einen Konsens.


Die Warnung kommt doch nur, wenn man die einzelnen ways taggt. Wenn
die tags dort sind, wo sie hingehören (Relation) gibt es AFAIK auch
keine Warnung.


+1   Es ist mehr ein Editor-Ding:

Wenn ich eine bestehende, basisgeometrische Fläche habe, also

-- mit Flächentag (z.B. landuse) getaggter closed way --

.. kann ich diesen closed way u.a. auf folgende Weise teilen

a) erzeuge n einzelne Segmente (neue ways)
weise --jedem Segment-- die Flächen-Tags des Originals zu

b) erzeuge ein multipolygon, addiere die n Segmente als outer
weise --dem multipolygon-- die Flächen-Tags des Originals zu

Die Funktion b) gibt es in Editoren bisher nicht  - das macht 
MapperIn zeitraubend step-by-step.
a) gibt es, liefert aber Müll, insofern man darauf aus ist, die 
originale Fläche zu behalten.


b) wäre eine Schnittstelle zwischen Flächenerfassung auf
- basisgeometrischer Grundlage (closed way) und
- relationaler Grundlage (relation + outer members)


outer members - 2+ Flächengrenzen
closed way - genau eine Flächengrenze
closed way  ==  relation mit closed way als outer member  (macht 
keiner, Spezialfall)



Ein Editor könnte auch beide Fälle näher aneinander führen - und dem 
Mapper von vornherein diesen Zusammenhang zeigen - indem jede Fläche als 
multipolygon erfasst wird.


Also, salopp formuliert, ich zeichne einen closed way und tagge ihn mit 
landuse=residential.
Ergebnis ist ein closed way und ein multipolygon mit (dem tag und dem 
closed way als member).


Der Vorteil dieses Verfahrens liegt auf der Hand:  Teile ich den closed 
way in der Basisgeometrie, werden die neuen Segmente korrekt in der 
gleichen Rolle in die Relation aufgenommen, die der closed way hatte.  
So etwas funktioniert nicht, wenn _nur_ der closed way mit Flächentag 
existiert, dann ist a) das Ergebnis.


Bitte beachten, dass nicht jeder closed way eine Fläche ist..
Was Fläche ist, wird in OSM durch tags auf closed ways bestimmt  
(area=yes, landuse, leisure, etc.).



Idealerweise müsste mich also der Editor fragen, ob ich ein multipolygon 
erstellen möchte (oder es gleich tun..), wenn er erkennt, dass ich einen 
closed-way mit einem Flächentag tagge.
In dem Fall, dass ich einen bereits vorhanden closed way mit 
Flächentag teile, sollte b) möglich sein.


Will man overlapping ways vermeiden, wäre dieses Editorverhalten die 
Lösung.  /Einen/ closed-way innerhalb einer multipolygon-Relation gäbe 
es nämlich immer nur solange, wie die Fläche isoliert von anderen ist.  
Sobald irgendeine andere Fläche, an den closed way grenzt, muss der 
closed way entsprechend fragmentiert werden - das multipolygon dazu 
wäre dann entweder schon da oder muss erstellt werden.  Echte isolierte 
Flächen dürften seeehr selten sein (z.B. eine Enklave ohne weitere 
Unterteilung und ohne tiefer verschachtelte Enklaven).


Overlapping ways sind eine Alternative dazu, Nachteile:
- Ablehnung durch eine nicht unbedeutende Zahl an Mappern
- algorithmisch aufwändigere Herstellung des Flächenbezugs
- höhere Fehleranfälligkeit

Overlapping ways sind in gewisser Weise das Produkt eines mangelnden 
Verständnisses des Bezuges zwischen Fläche und Flächengrenze, sprich des 
Bezuges von Flächen untereinander.  Overlapping ways machen den Fokus 
auf eine einzelne Fläche einfach, aber erschweren den Fokus auf das 
Flächengefüge/-netzwerk.  In Editorslang:
- Bei overlapping ways wird das Flächengefüge mittels 
durchklicken, bzw. durchrotieren ersichtlich
- Bei multipolygonen selektiere ich einen way und sehe das 
Flächengefüge in der Relationsliste  (i.e.  an welchen Flächen nimmt 
dieser way als Flächengrenze teil)


Der Vorteil von letzterem wird in Editoren dadurch zunichte gemacht, 
dass die Relationsliste nicht übersichtlich ist.  Angenommen, ich habe 
einen way, der an 5 Flächen-Relationen (type=multipolygon), 12 
Routen-Relationen (type=route), etc. teilnimmt - dann ist es mühsam, 
sich die passende Relation herauszupicken.  Auch deshalb nehmen evtl. 
viele von multipolygon Abstand.


Besserer Support für multipolygon und eine bessere Dokumentation des 
Flächen-Flächengrenzen-Bezugs (für alle Flächentypen, nicht nur für 
administrative Flächen, wie 

Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Fl

[Christian Müller]

Am 14.09.2011 14:59, schrieb Martin Koppenhoefer:

es gibt weltweit insgesamt 196 mal border in der Datenbank. Sind die
alle von Dir?


Nein, und das habe ich Dir schon gesagt:  Die sind nicht von mir.
Und /ja/, der key, der in OSM für das Taggen von Grenzen
verwendet wird ist, wie in den Relationen

/boundary/  und nicht  border


Sorry für diesen Fehler..  Also:

boundary=administrative
border_type=city


Aber weshalb dann nicht

boundary=administrative
boundary_type=city

?



Merken sollte man sich noch, dass

place als Fläche/area /hier/ bestritten wird (verschiedene Auffassungen),

im Wiki stand von Anfang an ausdruecklich, dass nodes und Flaechen
sinnvoll sind.


Nicht alles, was in einer Bibel steht, ist gut:
http://www.bibelzitate.de/gbz.html

Wie gesagt, das Wiki ist eine Karre.  An den Stellen, wo sie im Dreck 
steckt, muss man versuchen sie herausziehen.  Ein Indikator, wo sie im 
Dreck steckt, können stark unterschiedliche Auffassungen sein.  Evtl. 
gibt es Teile im Wiki, die nur sehr schwachen bis gar keinen Konsens 
haben/hatten oder sich mittlerweile überholt haben, weil mehr Wissen da 
ist.  Wiki, wie in Wikipedia - werden dort Dinge entdeckt, die nicht 
oder schlecht haltbar sind, fliegen sie auch raus und werden ersetzt..  
Auch Wikipedia, so verlässlich sie an vielen Stellen ist, ist kein 
Heiligtum, sondern ein Vehikel, dass sich fortbewegt - hoffentlich zum 
guten.



Gruß

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

Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]

[Christian Müller]

Am 14.09.2011 15:17, schrieb Garry:
Es ist ein Alleinstellungsmerkmal und erhöht die Auffindbarkeit 
solcher Besonderheiten.
Wenn Du z.B, eine OSM-Garminkarte verwendest in der aus Platzgründen 
keine Häuser dargestellt werden siehst Du an der Stelle
des Hauses nur Wald, ohne eigenem landuse ist so ein Haus dann auf der 
Karte unauffindbar.
Und nein, ich sehe dass nicht als Mappen für den Renderer an sondern 
ein Mappen der Realität zur besseren Nutzubarkeit der Daten.


Ich verstehe dein Anliegen vollkommen, solche Problem habe ich in der 
Datenweiterverarbeitung auch, aber das ist die Datennutzbarkeit /eines/ 
Anwendungsfalls.  Der nächste wird es genau anders brauchen..


Auch /deinem/ Anwendungsfall ist damit nicht geholfen, wenn dies das 
Ziel sein soll:


- jedes Haus hat irgendein Alleinstellungsmerkmal
- wenn auf dieser Grundlage landuse=* erfasst und fragmentiert wird,
bringt die Filterung von building=* bald nichts mehr..


Wenn Dir die Häuser im Wald wichtig sind, kannst Du auch /nur/ diese mit 
in die Karte aufnehmen.
Bessere Lösungen für deinen Anwendungsfall (Datenreduktion ohne 
Detailverlust im Wald) sind:


- filtere nur building=* aus den Daten, die innerhalb 
landuse=residential liegen


- tagge die building=* im Wald mit einem Alleinstellungs-tag  
(z.B.  secluded=yes), dann danach filtern


- place-node nutzen  (wenn die Häuser im Wald durch ein 
Toponymeinen Namen?  häufig schon..)



Es gibt keinen echten Grund /dafür/ (für dieses Problem) feingranulare 
landuse=* zu erfassen.  Da bieten andere Problemstellungen bessere 
Gründe, siehe unten..





Ich versteh Martin mit das Gebiet zweier dauerhaft bewohnter 
Häuserso dass er die Summe der beiden Grundstücke als eine 
landuse=residential
Fläche mappen und nicht die Gebäude selbst als einzelne 
landuse-Flächen mappen will.


Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten.  
Rechtfertigen


- ein/zwei einzelne Bäcker innerhalb einer Fläche, die 
überwiegend zum Wohnen genutzt wird
- ein/zwei Häuser innerhalb einer Fläche, die überwiegend durch 
die Forstwirtschaft genutzt wird


eine Extrafläche, oder nicht?


===
Ich denke wir sind uns alle einig, wenn wir sagen

landuse=* erfasst die reale Flächennutzung vor Ort

Worüber wir hier also noch diskutieren ist, ob vorrangig, 
überwiegend oder bedeutsam  mit in diese Definition aufgenommen 
werden sollte oder nicht.  Diese Attribute bestimmen aber _nicht_ die 
Granularität der Flächenausdehnung (Maßstab).  Die 'fuzzyness', um es 
mit Frederiks Worten zu sagen, brauchen wir auf _jedem_ Maßstab.  Egal 
wie klein der Flächeninhalt einer Fläche wird, ihr wird _nie_ eine 
'eindeutige' Nutzung zuschreibbar sein.  Es gibt immer mehrere 
Nutzungen, von denen aber eine oder mehrere überwiegen.



Eine Gebietsgröße, im Sinne einer Definition für die Flächenausdehnung 
eines landuse=* kann nicht gegeben werden, auch nicht als 
///Empfehlung///.  Wir werden keine quantitativen Zahlen angeben können, 
die definieren, dass eine Bodennutzungsfläche mindestens 1ha groß sein 
muss.  Weiterhin nicht, wieviele Leute es braucht, die das Gebiet auf 
eine bestimmte Weise nutzen, bevor ein extra landuse=* gerechtfertigt 
erscheint:  Es lässt sich


weder sagen, dass, wenn das Flächenverhältnis von kleinerer zu 
größerer Fläche  1/10 ist, wird die kleinere Fläche nicht erfasst,
noch sagen, dass 10 Menschen, die im Forst wohnen, die Bodennutzung 
eines Forstes zugunsten des Wohnens ändern.
noch sagen, landuse=* hat immer eine größere räumliche Ausdehnung 
als Gebäude


Einesorts kann es durchaus Gebäude geben, die ausdehnungsmäßig viel 
größer sind, als die Ausdehnung eines landuse anderenorts.  Wer es 
mathematisch exakt braucht, ermittle die durchschnittliche Größe aller 
Gebäudeflächen (GF) zum einen, und die aller Bodennutzungsflächen (BF) 
zum anderen.  Wenn die Werte in etwa gleich sind, oder BF  GF, hat das 
nichts mit dem bisherigen Verständnis von landuse=* zu tun, aber falsch 
im Sinne der angestrebten Bodennutzungsdefinition wäre es nicht.



===
Würden diese Fälle eintreten hätten wir ein MICROmapping von landuse=*, 
das dann aber bitte auf ISIC-Level 4..  Das als Ziel anzustreben, 
verprellt alle Nutzer, die an dieser Granularität nicht interessiert 
sind, also sollten wir explizit ///keine Empfehlung/// zur Granularität 
geben.


Das zeigt unsere Diskussion an sich - die Tatsache, das wir darüber 
diskutieren.  Für den einen ist die Fläche des Bäckers oder das Waldhaus 
im Wald nach dem Kriterium der Bodennutzung vernachlässigbar, für den 
anderen nicht.  Hier werden wir also nicht zusammenfinden.  Stattdessen 
können wir die Beziehung verschieden großer Flächen der Bodennutzungen 
untereinander erkennen und diese Struktur gemeinsam managen.  In 

Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]

[Christian Müller]

Hi,


Am 14.09.2011 11:23, schrieb Georg Feddern:




'vorrangige', reale Flächennutzung


Das ist durchaus eine sinnvolle, nicht-strikte Definition.
Aber warum erwartest Du dann, das man sich _strikt_ an eine nicht 
näher angegebene Größenordnung hält?

Wo muss man diese Größenordnung ziehen?


Erwarte ich nicht - siehe letzte mail + die mail zur Datenhaltung

'vorrangig'  bezieht sich sowieso nicht auf die Größenordnung, denn 
'vorrangig' oder 'überwiegend' ist auf bel. Größe/geograph. Ausdehnung 
ermittelbar..



Das Problem ist, dass die momentane Datenhaltung von landuses=*  mittels 
closed ways  uns nicht erlaubt, die Micromapper mit den Makromappern 
zusammenzubringen.



Deshalb kommt Quark dabei heraus, wenn sowohl ein Micromapper, als auch 
ein Makromapper landuse=* verwendet.
Der Micromapper zerlegt das Gebiet des Makromappers, obwohl die größere 
Fassung (Du schreibst, Deutschland besteht 'vorrangig' aus Agrarfläche), 
doch wohl auch Sinn macht!
Und -vice versa- killt der Makromapper mini-landuses von der 
OSM-Bildfläche, weil er der Meinung ist, ein landuse=*  sei  kein building=*



Nur aufgrund dieses Mißstands bestand von Anfang an der Wunsch 
landuse=*  größenordnungsmäßig zu begrenzen.
Weil wegen der technischen Art der Erfassung Micromapper und Makromapper 
nicht oder nur schlecht (overlapping ways..) koexistieren können.




.. verrauschtes  noise bitmap.

Nein, dass wären 'falsche' Renderregeln.


Angenommen ich würde jedes Grundstück mit einem einzelnen landuse=* 
taggen.  Stell Dir Mischgebiet vor.  Nun wird gerendert.  Ich zoome 
heraus, und voila:  Noise.  Der nächste Schritt ist, dass die 
Renderregeln angepasst werden, und erst auf einer tieferen Ebene 
landuse=* gerendert wird



Die Granularität bestimmt die Breite der definierten landuses. (Leider 
wird/wurde bei OSM oft zu schnell in die Breite gegangen, statt zu 
staffeln. :-( )


+1  bessere Staffelung ist eine Lösung des Problems..  zuviele Werte in 
einem key sind schlecht..  schlecht strukturierbar, schlecht für Einsteiger



Erstens endet die landuse-Granularität z. Z. spätestens an der 
Grundstücksgrenze - den so sinnlosen landuse=grass mal außen 
vorgelassen - und gleiche Nutzungen nebeneinander ergeben eine 
gemeinsame Fläche, im Zweifelsfall den von Martin angesprochenen Block 
(zwischen Verkehrswegen) - den man ja nicht auf Krampf unterteilen 
muss. Aber setzt sich der landuse=road durch, ist dort dann sowieso 
Schluss, falls sich der Schwebe-Ansatz nicht durchsetzt.


Mit multipolygons besteht das Problem nicht..  Da schwebt alles Makro 
dann über Micro, ohne sich zu stören.  Die Frage ist nur, ob man die 
Editoren soweit bringen kann, dass Mapper damit keine Probleme haben..



Und zweitens werden ab einem gewissen Zoomlevel landuses rendermäßig 
zusammengefasst (landwirtschaftlich, bebaut/besiedelt) sowie kleine 
Flächen weggelassen.


Das ist interessant.  Machen Renderer tatsächlich den Aufwand 
Flächengrößen zu berechnen, bevor gerendert wird?



.. (für jedes Gebäude finde ich unter Garantie 25 verschiedene 
Bodennutzungsarten ringsum).


Hier hätte ich gerne Belege für (diese Übertreibung) ...


;-)



  Das ist für landuse=*, useless=*..


Allerdings - aber in meinen Augen eben auch nicht zwangsläufig zu 
befürchten.
Insbesondere nicht, wenn man sinnvoll staffeln würde, statt weiter nur 
(oft unüberlegt) in die Breite zu gehen.


The thing is..  Staffelst Du sinnvoll, erhälst Du kleinere Flächen, weil 
die Staffelung dann ja (hoffentlich) auch für die Ausdifferenzierung der 
verfügbaren Fläche genutzt wird.  Damit gehen aber (ohne overlapping 
ways und ohne multipolygons) die Flächen verloren, welche die gröbere 
Einteilung, die gröbere Staffelung beinhalten.


Dein wie auch mein Argument dazu würde sein, dass man sich die gröberen 
Flächen ausrechnen kann - das zieht hier aber nicht:


- zum einen sind die Gebiete nicht immer ausrechenbar sind (z.B. 
dann nicht, wenn das gröbere Gebiet einen Namen hat - den müsstest Du 
dann auf jedem feingranularen Gebiet auch angeben, und das 
feingranularere Gebiet könnte dann keinen eigenen Namen mit name=* mehr 
erhalten)
- zum anderen sehr viele Leute die gröberen Gebiete verwenden (es 
damit Verschwendung wäre, wenn jeder für sich rechnet)


Wird ein grobes Gebiet unter Nutzung der Grenzen der feineren Gebiete 
mittels multipolygon erfasst, kann man auch nicht direkt davon sprechen, 
dass redundante Information in der DB wäre, denn es ist nur die 
Information enthalten, wie aus den feineren Gebieten, dass größere 
konstruiert wird).  Die Regel an sich ist redundant in der DB (wie 
konstruiere ich die Siedlungsfläche aus den micro-landuses), aber keine 
Daten.







Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels 
multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' 
Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag 
aufmachen, um landuse micromapping zu betreiben..
Denn landuse micromapping erhöht 

Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]

[Martin Koppenhoefer]

Am 15. September 2011 01:34 schrieb Christian Müller cmu...@gmx.de:
 Am 14.09.2011 15:17, schrieb Garry:
 Wenn Dir die Häuser im Wald wichtig sind, kannst Du auch /nur/ diese mit in
 die Karte aufnehmen.
 Bessere Lösungen für deinen Anwendungsfall (Datenreduktion ohne
 Detailverlust im Wald) sind:


wieso sollte das kein Detailverlust sein?

 Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten.


Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem
Bäcker im Wohngebiet.

Gruß Martin

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

Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]

[Martin Koppenhoefer]

Am 15. September 2011 02:22 schrieb Christian Müller cmu...@gmx.de:
 .. verrauschtes  noise bitmap.
 Nein, dass wären 'falsche' Renderregeln.
 Angenommen ich würde jedes Grundstück mit einem einzelnen landuse=* taggen.
  Stell Dir Mischgebiet vor.  Nun wird gerendert.  Ich zoome heraus, und
 voila:  Noise.  Der nächste Schritt ist, dass die Renderregeln angepasst
 werden, und erst auf einer tieferen Ebene landuse=* gerendert wird


Die Renderregeln können ja auch komplexer sein, als nur Flächen eines
bestimmten Landuses in einer bestimmten Farbe einzufärben. Wenn sich
im Laufe der Zeit dadurch, dass sich die Differenzierung der Welt auch
in OSM wiederfindet, in einem bestimmten zoomlevel die landuses zu
noise werden, wie Du befürchtest, dann könnte man z.B. - sofern die
Daten das hergeben - auch als Renderer herausfinden, dass ein
bestimmtes Gebiet eine bestimmte Nutzungsmischung hat, und das
grafisch in die Karte einarbeiten. Z.B. könnte man größere, gröbere
Gebiete automatisch aus feiner und differenzierter aufgelösten
Gebieten berechnen und sich dabei je nach Karte, die man erstellt,
entscheiden, welche Nutzungen man nicht differenzieren will, und
welche einem, wenn sie auch klein sein mögen, dennoch wichtig genug
sind, sie einzeln zu zeichnen.

Gruß Martin

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

Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu =?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal - Fl

[Martin Koppenhoefer]

Am 14. September 2011 19:28 schrieb Christian Müller cmu...@gmx.de:
 boundary=administrative
 border_type=city

 Aber weshalb dann nicht

 boundary=administrative
 boundary_type=city


m.E. reicht hier admin_level aus, border_type oder boundary_type
braucht man für administrative Grenzen, soweit ich das derzeit
überblicke, nicht. Für places brauche ich die auch nicht, weil der
place-Wert ja schon sagt, was es ist.

Gruß Martin

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

Re: [Talk-it] Aggiornamento elenco user-highways

[MorSi]

 non so se è il caso di contare anche highway=cycleway[1] visto che
 secondo la definizione sono strade, cosa ne pensano i ciclisti?
 
 [1] http://wiki.openstreetmap.org/wiki/IT:Tag:highway%3Dcycleway
 --
 Daniele Forsi
 

Per me le cycleway sono piste, percorsi ciclabili più che strade vere e proprie 
e tante vole non hanno nome.

Ciao
morsi


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

[Talk-it] R: Re: Aggiornamento elenco user-highways

[beppebo...@libero.it]

Scusa la mia ignoranza, nelle mappe mi sono imbattuto più volte nella dicitura 
fixme, viene considerata dal sistema con nome perchè numerose città medio 
piccole erano vuote o con questa dicitura
Giuseppe






Messaggio originale

Da: guido...@aedit.it

Data: 13/09/2011 20.07

A: openstreetmap list - italianotalk-it@openstreetmap.org

Ogg: Re: [Talk-it] Aggiornamento elenco user-highways




2011/9/13 Daniele Forsi dfo...@gmail.com


Il 13 settembre 2011 16:42, Stefano Tampieri ha scritto:



 Dalle statistiche di GFOSS [1], risutla che Torino e' la seconda

 citta' meglio mappata in Italia, con un indice di strade con nome del

 72%.

 come si fa a vedere una statistica del genere per una determinata città ?



da qui http://www.gfoss.it/osm/stat/ selezioni regione, provincia e

infine comune



Ho Aggiornato il sito di GFOSS ed adesso le statistoche comunali delle strade 
senza nome vengono calcolate solo considerando le seguenti tipologie:















'motorway','motorway_link','trunk','trunk_link','primary','primary_link','secondary',

secondary_link', 'tertiary', 'tertiary_link',  'unclassified', 'residential', 
'pedestrian',road', 'living_street') 


In questo modo si evita di considerare i track o i path senza nome ai fini 
della statistica. Modifico questa lista?
I comuni con più di 50.000 abitanti con la maggiore completezza dei nomi (94%) 
sono Forlì, Padova, Cesena e Parma.


Ciao,
Diego




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

Re: [Talk-it] R: Re: Aggiornamento elenco user-highways

[Tiziano D'Angelo]

Non deve mai essere name=fixme, ma piuttosto fixme=name / check name o altra
descrizione esplicativa

Ciao
T
Il giorno 14/set/2011 08:41, beppebo...@libero.it beppebo...@libero.it
ha scritto:
 Scusa la mia ignoranza, nelle mappe mi sono imbattuto più volte nella
dicitura fixme, viene considerata dal sistema con nome perchè numerose città
medio piccole erano vuote o con questa dicitura
 Giuseppe






 Messaggio originale

 Da: guido...@aedit.it

 Data: 13/09/2011 20.07

 A: openstreetmap list - italianotalk-it@openstreetmap.org

 Ogg: Re: [Talk-it] Aggiornamento elenco user-highways




 2011/9/13 Daniele Forsi dfo...@gmail.com


 Il 13 settembre 2011 16:42, Stefano Tampieri ha scritto:



 Dalle statistiche di GFOSS [1], risutla che Torino e' la seconda

 citta' meglio mappata in Italia, con un indice di strade con nome del

 72%.

 come si fa a vedere una statistica del genere per una determinata città ?



 da qui http://www.gfoss.it/osm/stat/ selezioni regione, provincia e

 infine comune



 Ho Aggiornato il sito di GFOSS ed adesso le statistoche comunali delle
strade senza nome vengono calcolate solo considerando le seguenti tipologie:















'motorway','motorway_link','trunk','trunk_link','primary','primary_link','secondary',

 secondary_link', 'tertiary', 'tertiary_link', 'unclassified',
'residential', 'pedestrian',road', 'living_street')


 In questo modo si evita di considerare i track o i path senza nome ai fini
della statistica. Modifico questa lista?
 I comuni con più di 50.000 abitanti con la maggiore completezza dei nomi
(94%) sono Forlì, Padova, Cesena e Parma.


 Ciao,
 Diego




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

Re: [Talk-it] R: Re: Aggiornamento elenco user-highways

[Diego Guidotti - Aedit s.r.l.]

2011/9/14 beppebo...@libero.it beppebo...@libero.it

 Scusa la mia ignoranza, nelle mappe mi sono imbattuto più volte nella
 dicitura fixme, viene considerata dal sistema con nome perchè numerose città
 medio piccole erano vuote o con questa dicitura


 Giuseppe


Si attualmente controllo solo che il nome non sia nullo, aggiungo il
controllo su fixme.

Ciao,
Diego
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Aggiornamento elenco user-highways

[Jeawrong]

Se clicco una specifica località (ad es. 
http://www.gfoss.it/osm/stat/?cod_com=43023
http://www.gfoss.it/osm/stat/?cod_com=43023 ) vedo solo lo stradario a
destra, a sinistra suppongo si dovrebbe vedere qualcosa di simile ad una
mappa, sbaglio? Ho provato con Opera 11.51 e IE8, ma non si vede nulla.

--
View this message in context: 
http://gis.638310.n2.nabble.com/Aggiornamento-elenco-user-highways-tp6725947p6791697.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Aggiornamento elenco user-highways

[Diego Guidotti - Aedit s.r.l.]

2011/9/14 Jeawrong jeawithl...@tin.it

 Se clicco una specifica località (ad es.
 http://www.gfoss.it/osm/stat/?cod_com=43023
 http://www.gfoss.it/osm/stat/?cod_com=43023 ) vedo solo lo stradario a
 destra, a sinistra suppongo si dovrebbe vedere qualcosa di simile ad una
 mappa, sbaglio? Ho provato con Opera 11.51 e IE8, ma non si vede nulla.


Errore del CSS, adesso dovrebbe andare su IEx. I dati si aggiornano
settimanalmente ma le mappe sono salvate in cache per non appesantire il
server, devo trovare un meccanismo di refresh senza appesantire troppo il
server.

Ciao,
Diego
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Aggiornamento elenco user-highways

[Jeawrong]

Ok, perfetto, funziona anche su Opera. Thanks :) !

--
View this message in context: 
http://gis.638310.n2.nabble.com/Aggiornamento-elenco-user-highways-tp6725947p6791865.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Aggiornamento elenco user-highways

[sabas88]

Adesso lo vedo anche io correttamente, belli gli edifici con effetto 3D,
sembra il visualizzatore di SardegnaMappe :)
Il refresh non lo fate solo sui tile dove ci sono state modifiche in quella
settimana?  Non converrebbe applicare il diff del database più spesso in
modo da dover generare un minor numero di tile ogni volta?
Ciao, Stefano

Il giorno 14 settembre 2011 11:47, Diego Guidotti - Aedit s.r.l. 
guido...@aedit.it ha scritto:



 2011/9/14 Jeawrong jeawithl...@tin.it

 Se clicco una specifica località (ad es.
 http://www.gfoss.it/osm/stat/?cod_com=43023
 http://www.gfoss.it/osm/stat/?cod_com=43023 ) vedo solo lo stradario a
 destra, a sinistra suppongo si dovrebbe vedere qualcosa di simile ad una
 mappa, sbaglio? Ho provato con Opera 11.51 e IE8, ma non si vede nulla.


 Errore del CSS, adesso dovrebbe andare su IEx. I dati si aggiornano
 settimanalmente ma le mappe sono salvate in cache per non appesantire il
 server, devo trovare un meccanismo di refresh senza appesantire troppo il
 server.

 Ciao,
 Diego



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


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

Re: [Talk-it] Aggiornamento elenco user-highways

[Stefano Salvador]

 highway di tipo 'motorway', 'trunk', 'primary', 'secondary',
 'tertiary', 'unclassified', 'residential' senza nome in base all'anno

ma le autostrade hanno nome ? di solito metto solo il ref, al più
indico il nome (tipo Autostrada Alpe Adria) solo nella route relation.
Idem per tutte le strade fuori dai centri urbani, se non ci sono case
di solito non ci sono neanche nomi di vie.

Ciao,

Stefano

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

Re: [Talk-it] Aggiornamento elenco user-highways

[Niccolo Rigacci]

On Wed, Sep 14, 2011 at 02:42:11PM +0200, Stefano Salvador wrote:
 
 ma le autostrade hanno nome ? di solito metto solo il ref, al più
 indico il nome (tipo Autostrada Alpe Adria) solo nella route relation.
 Idem per tutte le strade fuori dai centri urbani, se non ci sono case
 di solito non ci sono neanche nomi di vie.

Secondo me i nomi ci sono: Autostrada del Sole, Strada 
Regionale 2 Cassia, ecc. it.wikipedia.org di solito è abbastanza 
completa nel riportare il nome ufficiale e completo.

-- 
Niccolo Rigacci
Firenze - Italy
Tel. ufficio: 055-0118525

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

Re: [Talk-it] Aggiornamento elenco user-highways

[totera]

Diego Guidotti - Aedit s.r.l. wrote:
 
 Ho Aggiornato il sito di GFOSS ed adesso le statistoche comunali delle
 strade senza nome vengono calcolate solo considerando le seguenti
 tipologie:
 
 'motorway','motorway_link','trunk','trunk_link','primary','primary_link','secondary',secondary_link',
 'tertiary', 'tertiary_link', 'unclassified', 'residential',
 'pedestrian',road', 'living_street')
 

Visto che è una classificazione da usare provvisoriamente, penso che si
possa escludere road.

Ciao,
Gianluca

--
View this message in context: 
http://gis.638310.n2.nabble.com/Aggiornamento-elenco-user-highways-tp6725947p6792662.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] Ancora OSMIT: domani ultimo giorno per le presentazioni

[Maurizio Napolitano]

Forza ragazzuoli,
domani e' l'ultimo giorno per sottomettere qualcosa da presentare a OSMIT.
Al momento abbiamo un buon numero, ma piu' siamo meglio è.
È l'incontro degli utenti OpenStreetMap italiani, stiamo crescendo, e in
questo clima Open Data, molti stanno parlando di noi come ottimo esempio.
È una grande occasione :)

Ciao


-- 
Maurizio Napo Napolitano
http://de.straba.us

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

Re: [Talk-co] Tunja, origen de datos y Sogamoso

[Leonardo Gutierrez]

Yo si harrier, por fa.

Gracias

El día 13 de septiembre de 2011 22:48, Harrier Co
harrie...@hotmail.com escribió:

  Bueno por ahora lo mejor es que asumamos mas bien que es de pronto algun/a
 cartografo/a especializado, igual es muy dificil saber a veces el origen de
 datos, mil disculpas pero me causo impresion ver el progreso asi.

 Observe alguna imagen de Sogamoso de la NASA, hace dos años, con resolucion
 similar a una imagen de Duitama de ese entonces, alguien aun desea
 la referencia??

 harrierco

 ___
 Talk-co mailing list
 Talk-co@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-co





-- 
___
Leonardo Gutierrez
Director Financiero
Autobuses AGA de Colombia
Duitama
www.autobusesaga.com
l...@autobusesaga.com
Móvil: 3125860894


 Este mensaje de correo electrónico y sus documentos adjuntos están
dirigidos  EXCLUSIVAMENTE a los destinatarios especificados. La
información contenida puede ser CONFIDENCIAL y/o estar LEGALMENTE
PROTEGIDA y no necesariamente refleja la opinión de AUTOBUSES AGA DE
COLOMBIA LTDA. Si usted recibe este mensaje por ERROR, por favor
comuníquese inmediatamente al remitente y  ELIMINELO ya que usted  NO
ESTA AUTORIZADO al uso, revelación, distribución, impresión o copia de
toda o alguna parte de la información contenida.

___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-co] SOTM 2011

[hyan...@gmail.com]

Estimados maperos:

Buenas tardes, con base en los puntos del mensaje anterior, hago relación de
las gestiones avanzadas en Denver, donde además tuve la oportunidad de
participar en el encuentro del HOT [0]:

*1.  Fuentes de imágenes aéreas*
1.1.  Kate Chapman [1] nos informa que un funcionario del Gobierno
norteamericano está en la gestión de conseguir imágenes para las áreas
afectadas y que vamos a recibir ayuda al respecto.  Le propuse que las
hospedáramos en openstreetmap.co como WMS;
1.2.  Steve Coast (Bing): Hablé rápidamente con SteveC, dice que enviemos el
mensaje de las áreas necesitadas, Bing estará liberando imágenes continuas a
las actuales y es difícil atender todos los requerimientos debido a razones
de presupuesto;
1.3.  Globos:  Tengo un manual de Jeff Warren de http://publiclaboratory.org es
ya nuestra parte construirlos y ponerlos en práctica, luego lo escaneo y
comparto con la lista;
1.4.  Proyecto Afganistán:  Conocí a un colombiano que está desarrollando un
proyecto en Afganistán, ellos nos dicen que pueden preguntar por fotos para
Colombia, también trabajan con globos.  Estarán en el país para enero 2012;
1.5.  Nicolas Chavent del HOT Int. nos está apoyando para resolver el
misterio con las imágenes que se liberaron a partir de la segunda activación
del Space Charter para Colombia.  Esto directamente con Unitar-Unosat.  Al
parecer es un problema técnico con el JOSM; aunque está la duda si es del
WMS;

*2.  Articulación*
2.1.  Jhon Crowley de Harvard Humanitarian (el redactor del Disaster Report
2.0) trabaja por el desarrollo de un protocolo para la colaboración
interinstitucional, entre los países se encuentra Colombia;
2.2.  Gustó la idea de que OSM Colombia (al ser una entidad informal) nos
articulemos con instituciones amigas con el objeto de gestionar recursos.

*3.  Comunidad*
3.1.  Universidad de Colorado:  Están interesados en realizar intercambios
con sus estudiantes, ellos tienen la forma de buscar financiación para
proyectos.  Estos intercambios se harían con base en talleres de mapeo para
antender problemas específicos, lo cual se conecta con el siguiente punto.

*4.  Aplicaciones*
4.1.  Proyectos:  Kate Chapman nos pide que estructuremos los proyectos que
tenemos, una base para iniciar es la tabla en la Wiki 2011 [2], donde cada
área solicitada involucre uno  o varios proyectos (alcance, tiempo, costos).
 El objeto es buscarles financiación gestionada a través de las
instituciones amigas (partners).

Espero iniciar pronto con una actividad de mapeo en La Boquilla [3], con el
objeto de que reconozcan y aprovechen mejor su espacio geográfico (turismo,
etc).

Saludos cordiales,

Humberto Yances

[0]
http://hot.openstreetmap.org/weblog/2011/09/meeting-face-to-face-at-sotm-denver/
[1] http://wiki.openstreetmap.org/wiki/User:Wonderchook
[2]
http://wiki.openstreetmap.org/wiki/2011_Colombia_floods#Imagery_request_for_SOTM_2011
[3] http://www.openstreetmap.org/?lat=10.4847lon=-75.4983zoom=14layers=M

El 28 de agosto de 2011 20:23, hyan...@gmail.com hyan...@gmail.comescribió:

 Estimados maperos:

 Buenas noches, tengo el agrado de comunicarles que estaré humildemente
 representándoles en el próximo SOTM 2011

 http://stateofthemap.org/

 Quiero agradecerles a Fredy Rivera, Mike Dupont, Robert Soden, Ariel Núñez
 y Jean-Guilhem Cailton quienes postularon mi participación y beca por parte
 del evento, soy uno de los seis becados que estarán presentes.

 Los maperos de Colombia somos un grupo activo reconocido por la comunidad
 global, hemos ganado conciencia sobre lo importante que son las labores de
 mapeo en los distintos problemas que nos aquejan, tenemos todos los deseos
 de seguir abriendo caminos, trabajando con impulso constante para que cada
 vez sea mayor el impacto positivo de OSM en la sociedad civil y las
 instituciones.

 Les propongo que abramos temas o hilos sobre los cuales deseen (en la
 posibilidad de mis capacidades) haga gestiones en Denver.  Listo algunas
 sugerencias sobre las cuales les agradezco me ayuden a completar o mejorar:

 1.  Fuentes de imágenes aéreas:  Ya hay un hilo abierto para ello, por
 favor sigamos por allí.  Sería bueno poder armar un cuadro de cada una de
 las zonas o regiones con:  Limite geográfico (polígono); problemática
 (inundaciones, violencia, etc.); etnología (emberá-kathios...); propósito y
 responsable.

 2.  Articulación:  ¿Cómo facilitar la articulación de OSM y los productos
 que generamos con instituciones estatales, privadas o sin ánimo de lucro?

 3.  Comunidad: Estrategias para ampliar el grupo de maperos e intensificar
 su productividad a niveles prolíficos.  (Los talleres, fiesta de mapeo que
 hacemos y nuevas ideas).

 4.  Usos/aplicaciones: Listado de casos en Colombia, instituciones/personas
 que usan los productos de OSM.

 5.  Estado del Mapa:  Que lugares están bien mapeados; donde requerimos más
 trabajo.  Nivel de vías, nombres, etc.

 Reciban todos un cordial saludo y mil gracias,

 Humberto Yances

Re: [Talk-co] SOTM 2011

[hyan...@gmail.com]

3.2.  SMS Frontline: estuve compartiendo con un estudiante de la Universidad
de Washington para el tema de la cooperación técnica con SMS Frontline,
podemos crear una instancia en el servidor donado por el BM.  Los amigos de
Afganistan (el colombiano y sus dos socias) muestran interés en hacer el
trabajo de campo con una comunidad piloto para enero 2012.

4.2.  En la medida que tengamos proyectos para mapeo con las comunidades,
estaríamos disponibles para recibir GPStogo
http://wiki.openstreetmap.org/wiki/GPStogo

El 14 de septiembre de 2011 14:51, hyan...@gmail.com
hyan...@gmail.comescribió:

 Estimados maperos:

 Buenas tardes, con base en los puntos del mensaje anterior, hago relación
 de las gestiones avanzadas en Denver, donde además tuve la oportunidad de
 participar en el encuentro del HOT [0]:

 *1.  Fuentes de imágenes aéreas*
 1.1.  Kate Chapman [1] nos informa que un funcionario del Gobierno
 norteamericano está en la gestión de conseguir imágenes para las áreas
 afectadas y que vamos a recibir ayuda al respecto.  Le propuse que las
 hospedáramos en openstreetmap.co como WMS;
 1.2.  Steve Coast (Bing): Hablé rápidamente con SteveC, dice que enviemos
 el mensaje de las áreas necesitadas, Bing estará liberando imágenes
 continuas a las actuales y es difícil atender todos los requerimientos
 debido a razones de presupuesto;
 1.3.  Globos:  Tengo un manual de Jeff Warren de
 http://publiclaboratory.org es ya nuestra parte construirlos y ponerlos en
 práctica, luego lo escaneo y comparto con la lista;
 1.4.  Proyecto Afganistán:  Conocí a un colombiano que está desarrollando
 un proyecto en Afganistán, ellos nos dicen que pueden preguntar por fotos
 para Colombia, también trabajan con globos.  Estarán en el país para enero
 2012;
 1.5.  Nicolas Chavent del HOT Int. nos está apoyando para resolver el
 misterio con las imágenes que se liberaron a partir de la segunda activación
 del Space Charter para Colombia.  Esto directamente con Unitar-Unosat.  Al
 parecer es un problema técnico con el JOSM; aunque está la duda si es del
 WMS;

 *2.  Articulación*
 2.1.  Jhon Crowley de Harvard Humanitarian (el redactor del Disaster Report
 2.0) trabaja por el desarrollo de un protocolo para la colaboración
 interinstitucional, entre los países se encuentra Colombia;
 2.2.  Gustó la idea de que OSM Colombia (al ser una entidad informal) nos
 articulemos con instituciones amigas con el objeto de gestionar recursos.

 *3.  Comunidad*
 3.1.  Universidad de Colorado:  Están interesados en realizar intercambios
 con sus estudiantes, ellos tienen la forma de buscar financiación para
 proyectos.  Estos intercambios se harían con base en talleres de mapeo para
 antender problemas específicos, lo cual se conecta con el siguiente punto.

 *4.  Aplicaciones*
 4.1.  Proyectos:  Kate Chapman nos pide que estructuremos los proyectos que
 tenemos, una base para iniciar es la tabla en la Wiki 2011 [2], donde cada
 área solicitada involucre uno  o varios proyectos (alcance, tiempo, costos).
  El objeto es buscarles financiación gestionada a través de las
 instituciones amigas (partners).

 Espero iniciar pronto con una actividad de mapeo en La Boquilla [3], con el
 objeto de que reconozcan y aprovechen mejor su espacio geográfico (turismo,
 etc).

 Saludos cordiales,

 Humberto Yances

 [0]
 http://hot.openstreetmap.org/weblog/2011/09/meeting-face-to-face-at-sotm-denver/
 [1] http://wiki.openstreetmap.org/wiki/User:Wonderchook
 [2]
 http://wiki.openstreetmap.org/wiki/2011_Colombia_floods#Imagery_request_for_SOTM_2011
 [3]
 http://www.openstreetmap.org/?lat=10.4847lon=-75.4983zoom=14layers=M

 El 28 de agosto de 2011 20:23, hyan...@gmail.com hyan...@gmail.comescribió:

 Estimados maperos:

 Buenas noches, tengo el agrado de comunicarles que estaré humildemente
 representándoles en el próximo SOTM 2011

 http://stateofthemap.org/

 Quiero agradecerles a Fredy Rivera, Mike Dupont, Robert Soden, Ariel Núñez
 y Jean-Guilhem Cailton quienes postularon mi participación y beca por parte
 del evento, soy uno de los seis becados que estarán presentes.

 Los maperos de Colombia somos un grupo activo reconocido por la comunidad
 global, hemos ganado conciencia sobre lo importante que son las labores de
 mapeo en los distintos problemas que nos aquejan, tenemos todos los deseos
 de seguir abriendo caminos, trabajando con impulso constante para que cada
 vez sea mayor el impacto positivo de OSM en la sociedad civil y las
 instituciones.

 Les propongo que abramos temas o hilos sobre los cuales deseen (en la
 posibilidad de mis capacidades) haga gestiones en Denver.  Listo algunas
 sugerencias sobre las cuales les agradezco me ayuden a completar o mejorar:

 1.  Fuentes de imágenes aéreas:  Ya hay un hilo abierto para ello, por
 favor sigamos por allí.  Sería bueno poder armar un cuadro de cada una de
 las zonas o regiones con:  Limite geográfico (polígono); problemática
 (inundaciones, violencia, etc.); etnología (emberá-kathios...); propósito 

[Talk-dk] Korrektioner af vejnavne - sankt sanct

[Rasmus Vendelboe]

Hej alle,

Nogle gange er det gået liiige hurtigt nok når der er blevet oversat
vejnavne. Jeg har kigget på listen her i Århus og fandt umiddelbart, at 19
af de 74 navne ikke var godt nok oversat igår. Det er heldigvis de samme
fejl som går igen. St. skal nok oversættes Steen (når det er som i
St.St.Blicher), Chr./Chr bør være Christian og skt. er forkortelsen for
Sankt. Vi skal nok få dem fanget, men i opfordres lige en gang til at kigge
en ekstra gang inden de næste tusinde navne bliver oversat :).

Ved at skimme den totale korrektionsliste er jeg blevet opmærksom på folk
har oversat sct. til sanct. Det bør dog nævnes, at sanct altså ikke er en
autoriseret stavemåde (af DSN) af sankt. DSN's vejguide skriver rigtigt nok,
at man skal tage højde for traditionelle stavningsformer, men i og med vi
fjerner (den forkerte) forkortelsen skulle der ikke være grund for, at vi
derefter også oversætter den forkert fuldt ud. Sct. xxx er de historisk
korrekte navne - sankt må være den korrekte nutidige udskrivning af sct. Er
der nogen af dem der har oversat sct. der vil modargumentere?


Happy mapping.

Med venlig hilsen
Rasmus Vendelboe


ps. jeg har nu skrevet personligt til til de resterende af de 645 mest
aktive osm'ere på dansk grund [2], at de nu, for vores alles skyld, bør tage
stilling til ODBL. De der masseediterer bør besøge [3] og se hvor der er
licensproblemer. Det bliver nok noget rod hvis vi erklærer os vejfærdige
(ved 99%) og derefter får 1-5% slettet af OSMF.

[1] - http://osm.rasher.dk/tools/wrongnames.php?municipality_no=751
[2] - http://odbl.poole.ch/denmark-20110619-20110908-poly.html
[3] - http://osm.informatik.uni-leipzig.de/map/
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Korrektioner af vejnavne - sankt sanct

[Soren Johannessen]

 korrekte navne - sankt må være den korrekte nutidige udskrivning af sct. Er
 der nogen af dem der har oversat sct. der vil modargumentere?

Jeg vil godt vedr. disse her hvor der mangler et punktum i Sct at
kommunerne så retter til Sanct - Fordi dette kan kommunerne gøre uden
at skal lave partshøringer om ændringer

Fx et firma har på deres brevpapir/hjemmeside altid skrevet Sanct
Knuds Torv - Hvis ændring så bliver til Sankt Knuds Torv  så skal
der købes nyt brev papir etc. ændringer - hvilket kan koste penge for
firma - derfor ved væsentlige ændringer af historiske stavemåder kan
være problematiske da der måske skal en partshøring i gang og det er
administrativt tungt og dyrt.

Men hvis en kommune opretter en ny vej i dag så må de ikke lave denne
her Sanct XX jfr. stavereglerne så skal den hedde Sankt XX

Derfor er jeg for bibeholdelse af gammel stavemåde for Sct og ikke
vil større armbevægelser i gang for en ny og moderne stavemåde

Vh
Søren Johannessen

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Korrektioner af vejnavne - sankt sanct

[Soren Johannessen]

 Derfor er jeg for bibeholdelse af gammel stavemåde for Sct og ikke
 vil større armbevægelser i gang for en ny og moderne stavemåde

NB andet argument - nogen der fx har tjekket hvad der står IRL på
vejskiltene - hvis der fx står Sanct Knuds Torv men i vejnavne
registret er indsat som Sct Knuds Torv - Nogen gange er vejskilte
faktisk mere korrekte end hvad der officielt digitalt er blevet
registret

  det er også en lille smule dumt at måske kommuen skal bruge penge på
nye vejskilte til fx Sankt Knuds Torv eksemplet. Det kan da let
koste 5000 kr inkl. arbejdsløn eller mere at opsætte.

Ikke fordi dette her mit alter ego projekt mht stavemåden, men mere
pragmatisk af hensyn til hvordan kommunerne evt lettes kan gøre det jf
Sct uden punktum  Sanct

vh.
 Søren Johannessen

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Korrektioner af vejnavne - sankt sanct

[Jonas Häggqvist]

On 14-09-2011 20:24, Soren Johannessen wrote:

korrekte navne - sankt må være den korrekte nutidige udskrivning af sct. Er
der nogen af dem der har oversat sct. der vil modargumentere?


Jeg vil godt vedr. disse her hvor der mangler et punktum i Sct at
kommunerne så retter til Sanct - Fordi dette kan kommunerne gøre uden
at skal lave partshøringer om ændringer


Nu er vores ændringer jo ikke noget kommunerne er forpligtiget til at føre 
ud i livet. Vi ændrer bare vores egen data til at overholde de samme 
retningslinjer som kommunerne har.



Fx et firma har på deres brevpapir/hjemmeside altid skrevet Sanct
Knuds Torv - Hvis ændring så bliver til Sankt Knuds Torv  så skal
der købes nyt brev papir etc. ændringer - hvilket kan koste penge for
firma - derfor ved væsentlige ændringer af historiske stavemåder kan
være problematiske da der måske skal en partshøring i gang og det er
administrativt tungt og dyrt.


Vejen hedder jo i forvejen ikke Sanct X, men Sct. X. Spørgsmålet er 
hvordan vi skriver den forkortelse ud. Stavningen af en forkortelse er jo 
i øvrigt heller ikke nødvendigvis direkte udledt af den fulde stavemåde 
(fx fx).


Om det er svært eller dyrt for kommunen eller firmaer mener jeg ikke er et 
vigtigt argument i for vores brug. I sidste ende må det være noget 
kommunerne selv kan ligge og rode med. Hele øvelsen gik jo først og 
fremmest ud på at vi ikke skulle være afhængige af at kommunerne navngav 
deres veje korrekt.


At kommunerne så kan få vores rettelser at kigge på og gerne implementere 
dem er en sekundær ting i mine øjne.


--
Jonas Häggqvist
rasher(at)rasher(dot)dk

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Korrektioner af vejnavne - sankt sanct

[Soren Johannessen]

 At kommunerne så kan få vores rettelser at kigge på og gerne implementere
 dem er en sekundær ting i mine øjne.

Nu kan der så tænkes at folk der første gang ser OSM kort og ser at vi
skriver Sankt XX for de gader som digitalt i registrene er stavet
Sct XX og tænker her i byen har vi altid brugt denne her historiske
stavemåde Sanct XX og det står også på vores vejskilte - skikke
nogle amatører i OSM - Desuden søgemæssigt bør systemer tage højde for
evt. begge stavemåder

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Korrektioner af vejnavne - sankt sanct

[Jonas Häggqvist]

On 14-09-2011 22:59, Soren Johannessen wrote:


Nu er problematikken dem der er en direkte fejl med manglende punktum
i Sct kunne så skrives til kun Sct. med punktum i stedet for.


Men vejnavne bør ikke indeholde forkortelser - med mindre forkortelsen 
bliver udtalt (som fx DBU-Allé eller H.C. Andersens Vej). Det er både DS's 
og OSM's holdning. Så det er en fejl på lige fod med det manglende 
punktum. Jeg mener ikke vi kommer udenom det på den måde.


--
Jonas Häggqvist
rasher(at)rasher(dot)dk

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Korrektioner af vejnavne - sankt sanct

[Lars Thegler]

2011/9/14 Soren Johannessen soren.johannes...@gmail.com:
 Men vejnavne bør ikke indeholde forkortelser - med mindre forkortelsen
 bliver udtalt (som fx DBU-Allé eller H.C. Andersens Vej). Det er både DS's
 og OSM's holdning. Så det er en fejl på lige fod med det manglende punktum.
 Jeg mener ikke vi kommer udenom det på den måde.

Vi skal lige passe på at huske grundregelen:

  ... you should always enter the full name as it appears on the
street name signs

  (https://wiki.openstreetmap.org/wiki/Name)

Så hvad enten vi synes bedt om den ene eller dan anden stavemåde, så
må det som udgangspunkt være det, der står på skiltene, der bør fremgå
af OSM.

/Lars

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Korrektioner af vejnavne - sankt sanct

[Kent B. Hansen]

Hej,

Sct. er en forkortelse for Sanct, hvilket er den latinske stavemåde for
sankt. Nu er der vel ikke noget som forbyder at der bruges ikke-danske ord i
danske vejnavne, så jeg mener ikke man skal lave det om til Sankt.

Mvh.
Kent B. Hansen


Den 14. sep. 2011 22.32 skrev Peter Brodersen pe...@ter.dk:

 Hej,

 2011/9/14 Soren Johannessen soren.johannes...@gmail.com:
 
  At kommunerne så kan få vores rettelser at kigge på og gerne
 implementere
  dem er en sekundær ting i mine øjne.
 
  Nu kan der så tænkes at folk der første gang ser OSM kort og ser at vi
  skriver Sankt XX for de gader som digitalt i registrene er stavet
  Sct XX og tænker her i byen har vi altid brugt denne her historiske
  stavemåde Sanct XX og det står også på vores vejskilte - skikke
  nogle amatører i OSM - Desuden søgemæssigt bør systemer tage højde for
  evt. begge stavemåder

 Men er Sct overhovedet en forkortelse for Sanct og ikke fx
 Sankt? Jeg kan ikke finde ordet Sanct i ODS (1700-1950). Det kan
 godt være, at det er en tidligere gyldig staveform.

 Jeg holder til, at det bør være Sct. eller Sankt - ikke Sanct, idet
 intet peger på dette.

 --
 - Peter Brodersen

 ___
 Talk-dk mailing list
 Talk-dk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-dk

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-es] Nuevas Ortofotos de Castilla y León

[Sanjuan Vargas Machuca - Cristina]

Buenos días, al pinchar en la dirección me ha salido el error:

 

No se puede mostrar la página XML 

No se puede ver la entrada XML con la hoja de estilo . Corrija el error y haga 
clic en el botón Actualizar javascript:location.reload() , o inténtelo de 
nuevo más tarde. 



The download of the specified resource has failed. Error al procesar el recurso 
http://orto.wms.itacyl.es/Server/exception_...

 

 

Le he dado a ACTUALIZAR y nada.

Gracias



De: Manuel [mailto:manuelmi...@gmail.com] 
Enviado el: miércoles, 14 de septiembre de 2011 0:51
Para: Discusión en Español de OpenStreetMap
Asunto: Re: [Talk-es] Nuevas Ortofotos de Castilla y León

 

Siempre se agradece , a mi aun me queda mucho por poner en galicia, asi que no 
la utilizare por el momento


***
~  Un saludo cordial  de Manuel   ~
***
Mi sitio si te interesa mas información visita
El blog relacionado con linux # http://www.picholeiro.info .
Mi servidor # http://servidor.picholeiro.info http://picholeiro.sytes.net  .





El 13 de septiembre de 2011 16:42, Jorge Sanz Sanfructuoso sanc...@gmail.com 
escribió:

Las he añadido en la parte de Castilla y León donde estaban las otras del 
ITACyL. Creo que había otro sitio en la wiki donde también estaban las 
Ortofotos pero no me acuerdo donde

El 13 de septiembre de 2011 11:26, Alvaro Lara Cano y...@alvarolara.com 
escribió:

 

¿Sanchi, se podrian añadir al wiki, para tener una futura  referencia?





El 13/09/11 10:53, Jorge Sanz Sanfructuoso escribió: 

Hola 

Han actualizado las Ortofotos del ITACyL. En Salamanca por lo 
que puedo ver son fotos de principios del verano así que recientitas.




06/09/2011: Disponible las ortofotografias del año 2011 del 
cuadrante SW tanto mediante descarga del ftp (ftp://ftp.itacyl.es  
ftp://ftp.itacyl.es/ ohttp://ftp.itacyl.es http://ftp.itacyl.es/ ) como 
ortofotografía al vuelo en la capa Ortofoto_2011 del WMS. IMPORTANTE: Las 
orientaciones utilizadas para la generación de las orotofotos son las 
procedentes del sistema GPS/INS y son fruto de un proceso automático, por lo 
tanto están sujetos a ciertos errores geométricos y radiométricos. 

 

La dirección que hay que usar en JOSM es: 
wms:http://orto.wms.itacyl.es/Server/SgdWms.dll?FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=Ortofoto_2010;

 

Saludos

-- 

Jorge Sanz Sanfructuoso - Sanchi

Blog http://blog.jorgesanzs.com/






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

 


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





 

-- 

Jorge Sanz Sanfructuoso - Sanchi

Blog http://blog.jorgesanzs.com/


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

 

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

Re: [Talk-es] Nuevas Ortofotos de Castilla y León

[Jorge Sanz Sanfructuoso]

Las ortofotos son para utilizarlas por ejemplo en JOSM. No funcionan
directamente desde la dirección. Aquí tienes un videotutorial de como
configurar JOSM y te viene como usar estos servidores WMS  de ortofotos:
http://youtu.be/Bs_cevxBdU8

El 14 de septiembre de 2011 08:21, Sanjuan Vargas Machuca - Cristina 
cristina.sanj...@promojaen.es escribió:

 **

 Buenos días, al pinchar en la dirección me ha salido el error:

 ** **

 No se puede mostrar **la página XML** 

 No se puede ver **la entrada XML** con la hoja de estilo . Corrija el
 error y haga clic en el botón Actualizar, o inténtelo de nuevo más tarde.
 
  --

 *The download of the specified resource has failed. **Error al procesar el
 recurso http://orto.wms.itacyl.es/Server/exception_...*

  

 ** **

 Le he dado a ACTUALIZAR y nada.

 Gracias
  --

 *De:* Manuel [mailto:manuelmi...@gmail.com]
 *Enviado el:* miércoles, 14 de septiembre de 2011 0:51
 *Para:* Discusión en Español de OpenStreetMap
 *Asunto:* Re: [Talk-es] Nuevas Ortofotos de Castilla y León

 ** **

 Siempre se agradece , a mi aun me queda mucho por poner en galicia, asi que
 no la utilizare por el momento


 *
 *~  Un saludo cordial  de Manuel   ~*
 *
 *Mi sitio si te interesa mas información visita*
 El blog relacionado con linux # http://www.picholeiro.info .
 Mi servidor # http://servidor.picholeiro.infohttp://picholeiro.sytes.net.



 

 El 13 de septiembre de 2011 16:42, Jorge Sanz Sanfructuoso 
 sanc...@gmail.com escribió:

 Las he añadido en la parte de Castilla y León donde estaban las otras del
 ITACyL. Creo que había otro sitio en la wiki donde también estaban las
 Ortofotos pero no me acuerdo donde

 El 13 de septiembre de 2011 11:26, Alvaro Lara Cano y...@alvarolara.com
 escribió:

 ** **

 ¿Sanchi, se podrian añadir al wiki, para tener una futura  referencia?





 El 13/09/11 10:53, Jorge Sanz Sanfructuoso escribió: 

 Hola 

 Han actualizado las Ortofotos del ITACyL. En Salamanca por lo que puedo ver
 son fotos de principios del verano así que recientitas.


 

 *06/09/2011: *Disponible las ortofotografias del año 2011 del cuadrante SW
 tanto mediante descarga del ftp (ftp://ftp.itacyl.es ftp://ftp.itacyl.es/
 ohttp://ftp.itacyl.es) como ortofotografía al vuelo en la capa *
 Ortofoto_2011* del WMS. *IMPORTANTE:* Las orientaciones utilizadas para
 la generación de las orotofotos son las procedentes del sistema GPS/INS y
 son fruto de un proceso automático, por lo tanto están sujetos a ciertos
 errores geométricos y radiométricos. 

 ** **

 La dirección que hay que usar en JOSM es: wms:
 http://orto.wms.itacyl.es/Server/SgdWms.dll?FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=Ortofoto_2010;
 

 ** **

 Saludos

 -- 

 Jorge Sanz Sanfructuoso - Sanchi

 Blog http://blog.jorgesanzs.com/



 

 ___

 Talk-es mailing list

 Talk-es@openstreetmap.org

 http://lists.openstreetmap.org/listinfo/talk-es

 ** **


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



 

 ** **

 -- 

 Jorge Sanz Sanfructuoso - Sanchi

 Blog http://blog.jorgesanzs.com/


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

 ** **

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




-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://blog.jorgesanzs.com/
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

[Talk-es] Mapa

[Carlos . Navarro]

Buenas tardes.

Hace unos días me presenté como nuevo y estuve preguntando cómo obtener 
shapefiles a través de OSM. Al final lo conseguí con las indicaciones de 
Jesús Gómez, y ahora que tengo el mapa de un zoom determinado en 
shapefile, la capa sólo tiene datos de las calles, nada de sentido, por 
ejemplo. ¿Cómo puedo entonces hacer una ruta? ¿Debo descargar otro 
formato?

Gracias de nuevo.
 
Carlos Navarro Quesada - Departamento de Nuevas Tecnologías

ZEROEMISSIONS
Campus Palmas Altas
Edificio B, planta 3ª, puesto 003
C/ Energía Solar nº 1, 41014, Sevilla
Phone: +34954970466 (38466)  Fax: +34955413374
carlos.nava...@zeroemissions.abengoa.com 
www.zeroemissions.com - www.abengoa.com
P Eco-Tip: Printing e-mails is usually a waste. 
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Mapa

[Aurélien FILEZ]

Hola buenas,

Si tu mapa utiliza los datos des OSM, puedes hacer una ruta sobre la web de
www.openstreetmap.org y utilizar el editor de la web que se llama
Potlatchhttp://wiki.openstreetmap.org/wiki/Potlatch_2.
Tambien, hay un instrumiento que se llama
JOSMhttp://josm.openstreetmap.de/ que
es lo mismo pero de un desktop mañera.

Cuando haz echo la ruta, puedes regenerar tu mappa con la misma technica que
ahora, y tu ruta sera integrada.

Ciao !

2011/9/14 carlos.nava...@zeroemissions.abengoa.com

 Buenas tardes.

 Hace unos días me presenté como nuevo y estuve preguntando cómo obtener
 shapefiles a través de OSM. Al final lo conseguí con las indicaciones de
 Jesús Gómez, y ahora que tengo el mapa de un zoom determinado en shapefile,
 la capa sólo tiene datos de las calles, nada de sentido, por ejemplo. ¿Cómo
 puedo entonces hacer una ruta? ¿Debo descargar otro formato?

 Gracias de nuevo.

 Carlos Navarro Quesada - Departamento de Nuevas Tecnologías

 ZEROEMISSIONS
 Campus Palmas Altas
 Edificio B, planta 3ª, puesto 003
 C/ Energía Solar nº 1, 41014, Sevilla
 Phone: +34954970466 (38466)  Fax: +34955413374
 carlos.nava...@zeroemissions.abengoa.com
 www.zeroemissions.com - www.abengoa.com
 P Eco-Tip: Printing e-mails is usually a waste.

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


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

Re: [Talk-es] Nuevas Ortofotos de Castilla y León

[Simó]

Hola,

On Tue, 13 Sep 2011 16:42:47 +0200, Jorge Sanz Sanfructuoso wrote:

Las he añadido en la parte de Castilla y León donde estaban las
otras del ITACyL. Creo que había otro sitio en la wiki
donde también estaban las Ortofotos pero no me acuerdo donde


Quizas te refieres a la siguiente pagina donde hay otro enlace para el 
WMS de ITACyL


http://wiki.openstreetmap.org/wiki/Spain_Potential_Datasources

Hasta pronto.

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

Re: [Talk-es] Mapa

[Iván Sánchez Ortega]

El día Wednesday 14 September 2011 16:34:02, 
carlos.nava...@zeroemissions.abengoa.com dijo:
 Hace unos días me presenté como nuevo y estuve preguntando cómo obtener
 shapefiles a través de OSM. Al final lo conseguí con las indicaciones de
 Jesús Gómez, y ahora que tengo el mapa de un zoom determinado en
 shapefile, la capa sólo tiene datos de las calles, nada de sentido, por
 ejemplo. ¿Cómo puedo entonces hacer una ruta? ¿Debo descargar otro
 formato?

Comprueba si los datos en shapefile incluyen un atributo llamado oneway. 
Cuando ese atributo es yes, esa vía es de sentido único, en el sentido en 
el que está dibujada.

No sé exactamente cómo hacer rutas con OSM, pero creo que hay algún script 
para cargar los datos (y procesar los oneways y restricciones) en un PostGIS. 
Échale un vistazo al wiki.



-- 
Iván Sánchez Ortega i...@sanchezortega.es

Un ordenador no es una televisión ni un microondas: es una herramienta 
compleja.

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

Re: [Talk-es] Mapa

[Oscar Fonts]

 No sé exactamente cómo hacer rutas con OSM, pero creo que hay algún script
 para cargar los datos (y procesar los oneways y restricciones) en un PostGIS.

Hay un workshop del FOSS4G routing with pgRouting tools,
OpenStreetMap road data and GeoExt, cuyos materiales están en:

http://workshop.pgrouting.org/

Salut.

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

Re: [Talk-es] Mapa

[Jaime Crespo]

El día 14 de septiembre de 2011 20:32, Oscar Fonts
oscar.fo...@gmail.com escribió:
 No sé exactamente cómo hacer rutas con OSM, pero creo que hay algún script

También se pueden procesar directamente los archivos XML .osm y
utilizar software de cálculo de rutas como Gosmore:

http://wiki.openstreetmap.org/wiki/Gosmore

-- 
Jaime Crespo

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

[Talk-ar] Calles del tipo viveza criolla

[Javier Argentina]

¿Cómo clasifican las calles que se arman en forma natural gracias
a la viveza criolla al costado de las autopistas, hechas para ir a
contramano de la viía asfaltada, de manera de esquivar una rotonda o
un sistema de tránsito?
Aclaro que tiene casi 2 km de largo.
Se me ocurrió ponerle callejón (alley).
Para visualizarla, uno de sus nodos es el 1432897187 (-32.4881434 -58.3081436)

JAP

___
Talk-ar mailing list
Talk-ar@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ar

Re: [Talk-ar] Buenos Aires: Flores

[Julio Costa Zambelli]

Pablo,

Fíjate que _en un tramo_ (¿J.B.Alberdi hasta Tandil/Italia?) de la que ahora
se llama Bolivia, la borrada decía Varela.

Saludos,

Julio Costa Zambelli
OpenStreetMap Chile

julio.co...@openstreetmap.cl

http://www.openstreetmap.cl/
Cel: +56(9)89981083
Postal: Casilla 9002, Correo 3, Viña del Mar, Chile



2011/9/13 Pablo Daniel Pareja Obregón parejaobre...@gmail.com

 Gracias! Ya las estoy corrigiendo...

 2011/9/13 Julio Costa Zambelli julio.co...@openstreetmap.cl:
  Estimado Pablo,
  Si ingresas a la zona con Potlatch 1 y combinas Control+U
  te aparecerán las vías eliminadas del sector (en rojo), seleccionas la
 que
  te interesa, tomas el ID y lo agregas a la URL a continuación para saber
  quien las borro.
  Por lo que veo en las calles que faltan
  (http://www.openstreetmap.org/browse/way/22277844 y
 http://www.openstreetmap.org/browse/way/46930748),
  las habría borrado un usuario barrio caballito
  (http://www.openstreetmap.org/user/barrio%20caballito) en el Changeset
  8972474 (http://www.openstreetmap.org/browse/changeset/8972474).
  Saludos,
  Julio Costa Zambelli
  OpenStreetMap Chile
  julio.co...@openstreetmap.cl
  http://www.openstreetmap.cl/
  Cel: +56(9)89981083
  Postal: Casilla 9002, Correo 3, Viña del Mar, Chile
 
 
  2011/9/13 Pablo Daniel Pareja Obregón parejaobre...@gmail.com
 
  Buenas,
 
  A raíz del accidente que esta por todas las noticias, estaba
  chusmeando la zona de la plaza pellegrini en Flores...
 
  No conozco mucho la zona, pero puede ser que falte un tramo de la
  calle Bolivia y otro de la calle Pedernera [1]? Quizás se borró
  accidentalmente... si logramos encontrar el commit sería interesante
  para agregar cualquier otra cosa que se pueda haber quitado... sino
  agregamos los tramos a mano ya que son sólo un par de cuadras.
 
  Saludos,
  Pablo
 
  --
  [1]
 
 http://www.openstreetmap.org/?lat=-34.63282lon=-58.46347zoom=17layers=M
 
  ___
  Talk-ar mailing list
  Talk-ar@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ar
 
 

___
Talk-ar mailing list
Talk-ar@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ar

Re: [Talk-ar] Buenos Aires: Flores

[Pablo Daniel Pareja Obregón]

¡Gracias!

Corregido (desde la calle rivadavia).

2011/9/14 Julio Costa Zambelli julio.co...@openstreetmap.cl:
 Pablo,
 Fíjate que _en un tramo_ (¿J.B.Alberdi hasta Tandil/Italia?) de la que ahora
 se llama Bolivia, la borrada decía Varela.
 Saludos,
 Julio Costa Zambelli
 OpenStreetMap Chile
 julio.co...@openstreetmap.cl
 http://www.openstreetmap.cl/
 Cel: +56(9)89981083
 Postal: Casilla 9002, Correo 3, Viña del Mar, Chile


 2011/9/13 Pablo Daniel Pareja Obregón parejaobre...@gmail.com

 Gracias! Ya las estoy corrigiendo...

 2011/9/13 Julio Costa Zambelli julio.co...@openstreetmap.cl:
  Estimado Pablo,
  Si ingresas a la zona con Potlatch 1 y combinas Control+U
  te aparecerán las vías eliminadas del sector (en rojo), seleccionas la
  que
  te interesa, tomas el ID y lo agregas a la URL a continuación para saber
  quien las borro.
  Por lo que veo en las calles que faltan
 
  (http://www.openstreetmap.org/browse/way/22277844 y http://www.openstreetmap.org/browse/way/46930748),
  las habría borrado un usuario barrio caballito
  (http://www.openstreetmap.org/user/barrio%20caballito) en el Changeset
  8972474 (http://www.openstreetmap.org/browse/changeset/8972474).
  Saludos,
  Julio Costa Zambelli
  OpenStreetMap Chile
  julio.co...@openstreetmap.cl
  http://www.openstreetmap.cl/
  Cel: +56(9)89981083
  Postal: Casilla 9002, Correo 3, Viña del Mar, Chile
 
 
  2011/9/13 Pablo Daniel Pareja Obregón parejaobre...@gmail.com
 
  Buenas,
 
  A raíz del accidente que esta por todas las noticias, estaba
  chusmeando la zona de la plaza pellegrini en Flores...
 
  No conozco mucho la zona, pero puede ser que falte un tramo de la
  calle Bolivia y otro de la calle Pedernera [1]? Quizás se borró
  accidentalmente... si logramos encontrar el commit sería interesante
  para agregar cualquier otra cosa que se pueda haber quitado... sino
  agregamos los tramos a mano ya que son sólo un par de cuadras.
 
  Saludos,
  Pablo
 
  --
  [1]
 
  http://www.openstreetmap.org/?lat=-34.63282lon=-58.46347zoom=17layers=M
 
  ___
  Talk-ar mailing list
  Talk-ar@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ar
 
 



___
Talk-ar mailing list
Talk-ar@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ar

[Talk-ar] San Isidro

[Julio Costa Zambelli]

Aprovechando el paseo a Tigre que hice el Domingo pasado, agregue las
estaciones que faltaban en el Tren de la Costa, y algunas otras cosas
(Restaurant, Café, Catedral, etc.) en San Isidro. En le proceso borre la
calle que conectaba el frente de la Catedral de San Isidro y la calle Juan
Bautista de Lasalle, por el costado sur-este de la Plaza Mitre,
pues según recuerdo esa calle no estaba ahí (en la imagen de Bing solo se
ven arboles). Creo que hay una bajada peatonal (
http://www.panoramio.com/photo/33744323), pero seria ideal que alguien con
mayor conocimiento local confirmara.

Saludos,

Julio Costa Zambelli
OpenStreetMap Chile

julio.co...@openstreetmap.cl

http://www.openstreetmap.cl/
Cel: +56(9)89981083
Postal: Casilla 9002, Correo 3, Viña del Mar, Chile
___
Talk-ar mailing list
Talk-ar@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ar

Re: [Talk-ar] Puesto de control militar

[Pablo Daniel Pareja Obregón]

Si te referís al POI, supongo que con el tag barrier=gate está bien.
También puede ser barrier=lift_gate, dependiendo del tipo de acceso.
El tag landuse=military sería más bien usado para encerrar el área
alrededor de la zona militar.

Corríjanme si estoy equivocado...

Saludos,
Pablo

On Wed, Sep 14, 2011 at 5:12 PM, Javier Argentina
javier.debian.bb...@gmail.com wrote:
 Preguntonta:

 ¿Cómo marco un puesto de control de acceso a una guarnición militar?

 ¿landuse - military?

 No me cierra el landuse.

 JAP

 ___
 Talk-ar mailing list
 Talk-ar@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ar


___
Talk-ar mailing list
Talk-ar@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ar

Re: [Talk-ar] Puesto de control militar

[JAP]

El 14/09/11 17:23, Pablo Daniel Pareja Obregón escribió:

On Wed, Sep 14, 2011 at 5:12 PM, Javier Argentina
javier.debian.bb...@gmail.com  wrote:

Preguntonta:

¿Cómo marco un puesto de control de acceso a una guarnición militar?

¿landuse - military?

No me cierra el landuse.

JAP

___
Talk-ar mailing list
Talk-ar@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ar



Si te referís al POI, supongo que con el tag barrier=gate está bien.
También puede ser barrier=lift_gate, dependiendo del tipo de acceso.
El tag landuse=military sería más bien usado para encerrar el área
alrededor de la zona militar.

Corríjanme si estoy equivocado...

Saludos,
Pablo

Me gusta esto de la barrera, porque el área ya tenía pensado marcarla como 
landuse.

Gracias.

JAP


___
Talk-ar mailing list
Talk-ar@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ar

[Talk-at] Verantwortungsvoller Umgang mit der Karte (war: Re: OT: Schreikrampf (war: 1-2 Fragen für einen Neuling))

[David Schmitt]

On 02.09.2011 02:15, Lukas Bischof wrote:

Letztendlich denke ich bei jedem Klick immer noch nach, ob ich ihn
richtig mache, lasse nicht zu, dass die Routine eintritt.

In der Hoffnung, dass ich keine Schreikrämpfe auslöse,


Neue Mapper, die mitlesen (-schreiben und -denken) und sich für den 
Hintergrund interessieren sind immer willkommen :-)



MfG David

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

Re: [Talk-at] Graz (oder anderes): Wie kann ich sinnvoll beitragen?

[Boris Cornet]

Servus!

Gestern (Mi, 14. September 2011) schrieb Michael Maier:

 Da sind wir in Graz erst dabei, Priorities festzulegen ;-)

Wie wäre es, auch das große Aufräumen bei plan.at Daten auf die Liste
zu setzen? Es gibt auch in der Steiermark noch einige Flecken, wo Not
am Mann wäre, siehe http://www.osm-at.org/plan_at/status/ [1] und z.B.
http://geotools.ipax.at/index.php?zoom=12lat=47.10357lon=15.196layers=B0Tchecks=15%2C12%2C13

-- 
Bis demnächst,
   Boris

[1]  demnächst gibt es wieder einen update...


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

Re: [Talk-ca] What should a Canadian style map look like?

[AJ Ashton]

One aspect of the map that is not a uniquely Canadian problem, but is
perhaps more significant here than in other places is how temporal
objects  spaces should be handled. Many important aspects of mappable
life change distinctly between summer  winter - ice rinks,
recreational trails, usability of roads, availability of certain
services, etc.

Perhaps this specific type of temporality - summer vs winter - could
use some well-defined visual  data conventions to make them easier to
see  understand than current approaches to intermittent/temporary
objects in general.

Maybe we'd even seasonal map stylesheets :)

AJ Ashton

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

Re: [Talk-ca] What should a Canadian style map look like?

[Richard Weait]

On Wed, Sep 14, 2011 at 12:48 PM, AJ Ashton aj.ash...@gmail.com wrote:
 One aspect of the map that is not a uniquely Canadian problem, but is
 perhaps more significant here than in other places is how temporal
 objects  spaces should be handled. Many important aspects of mappable
 life change distinctly between summer  winter - ice rinks,
 recreational trails, usability of roads, availability of certain
 services, etc.
br/
 Perhaps this specific type of temporality - summer vs winter - could
 use some well-defined visual  data conventions to make them easier to
 see  understand than current approaches to intermittent/temporary
 objects in general.

 Maybe we'd even seasonal map stylesheets :)


Ice roads, Dude.  Totally, ice roads.  ;-)

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

Re: [Talk-ca] What should a Canadian style map look like?

[Adam Glauser]

On 9/12/2011 6:32 PM, Richard Weait wrote:

Just brain-storming, so let's have suggestions without debate for now.
  What should the OSM data look like when styled for Canadians?


I like the suggestions so far. I'd add
 - First Nations borders
 - Crown land boundries
 - special rendering for notable relations like the Trans-Canada Highway

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

[Talk-cz] administrativní hranice a place=*

[Petr Morávek [Xificurk]]

Petr Morávek [Xificurk] napsal(a):
 jzvc napsal(a):
 co je horsi (a nevim
 jak moc to jeste zustalo) ze nektery uzemi byly spatne zarazeny do
 struktury (rodic - potomek) takze sem napr narazel na uzemi nejen mimo
 dany okres, ale i kraj ...
 
 Tohle se mi snad podaří odchytnout, už jsem na pár takových případů narazil.

Tak hierarchie ČR  oblast  kraj  okres  obec by měla být spravená,
na opravu ještě čeká správné zařazení obec  KÚ. Momentálně ale opravuji
důležitější problém - mnoho obcí má špatné nebo žádné administrativní
centrum. Nicméně v průběhu těchto oprav jsem narazil na jednu věc, která
se tu už řešila a která mně osobně vadí už delší dobu - tag place.

Spousta vesnic (včetně mnoha, které figurují jako administrativní
centrum obce) je v ČR označena jako place=suburb, bléé :/
Proč je to špatně:
1) Suburb znamená městská část, sídliště, předměstí atp. a přesně takto
je to na OSM wiki popisováno.
2) Nikde (prošel jsem sousední státy) se takto vesnice neznačí,
většina sídel je značena village a town, velká města pak city, a
výjimečně některé malé osady jako hamlet. A skutečně je jedno kolik
takových sídel je uvnitř jedné obce (gemeinde, gmini).

Rád bych, aby se tohle konečně nějak vyřešilo, navrhuji:
1) Pokud má vesnice samostatnou ceduli začátku/konce obce, je to city,
town, nebo village:
a) Pro city nechat současný stav.
b) Otázkou je, jak rozhodnout town/village - raději bych zkusil
najít jinou metriku, než oficiální statut města, který moc neodpovídá
reálné rozvinusti sídla.
2) Hamlet nechat pro pojmenované malé vísky, samoty atp., které nemají
vlastní ceduli začátku/konce obce (protože tam často nevede ani žádná
silnice III. třídy).
3) Suburb používat pro městské části, čtvrti, vesnice pohlcené městy...
poznávacím znamením je neexistence vlastní cedule začátku/konce obce,
protože už se nachází uvnitř nějakého města (které tu vlastní ceduli má).

Pokud se rychle nikdo neozve, tak v příštích dnech dokončím opravu
administrativních center obcí. Následně pak všechna taková sídla, co v
současnosti nemají place=city,town,village, aktualizuji na place=village.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] boundary=postal_code (était : admin_level = 9)

[Christian Quest]

Les cas particuliers peuvent être intéressants...

A l'aide de http://www.presse-poste.com/vos-outils/testez-vos-adresses
j'ai testé les limites entre St Maur des Fossés et La Varenne St
Hilaire, cas que je connais bien étant moi même de St Maur.

J'ai l'impression que certaines adresses (exemple le 87 rue Viala)
peuvent prendre les deux codes postaux (94100 et 94210) ou alors c'est
un défaut de l'outil mis à disposition par La Poste.

N'étant pas germanophone, j'espère avoir compris le principe surtout
pour ce qui est du découpage fin des rues à la frontière.
En effet, au moins deux cas se présentent:
- les deux côtés de la rue ont le même code postal,
- chaque côté de la rue a un code postal différent
et parfois un troisième cas: celui du double code postal.

A titre de test, j'ai créé les deux relations comme indiqué ici:
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010
http://www.openstreetmap.org/browse/relation/1751952
http://www.openstreetmap.org/browse/relation/1751953

--
Christian

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Josm : type de relation inconnu

[Agnès Rambaud]

Christian Quest a écrit :

(..)



J'ai créé un arrêt (un noeud) et un quai pour les passagers en attente
(area), comme vu ici :
http://wiki.openstreetmap.org/wiki/FR:Key:public_transport
Puis j'ai créé - avec josm - une relation où j'ai mis comme membres l'arrêt
et le quai.

Pourtant, JOSM râle en me disant que le type de relation est inconnu. Sauf
que j'arrive pas à piger pourquoi...
(..)
Agnès

Je pense que ce type de relation est juste inconnu du validator de
JOSM... et ce n'est pas le seul type, le validator ne connait pas
tout.


Ok. Ça me rassure.
Je peux continuer alors.

Merci.
Agnès

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level = 9

[Nicolas Dumoulin]

Le Mercredi 14 Septembre 2011 10:26:14 Ab_fab, vous avez écrit :
 Merci Nicolas pour cette (encore) bonne idée,
 
 Le genre de carte que l'on ne trouve nulle part, qui rendrait probablement
 service à pas mal de monde au quotidien ...
 ... bref, de quoi faire parler d'un projet comme OSM !
 
 Ton script agrège les communes adjacentes qui ont le même code postal, pour
 ne montrer que la délimitation extérieure du CP ?

Voilà, tout à fait.
Voilà en PJ mon script avec les deux couches mapnik et leur bête requête.
Ce script utilise une petite bibliothèque python qui me facilite grandement 
l'utilisation de mapnik (ça se voit dans le script :-) ) :
https://code.launchpad.net/~nicolas-dumoulin/+junk/mapnik-easymap

Je peux tenter de générer toute la France …

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys, os
from easymap.easymap2 import *
from generate_tiles2 import render_tiles

if __name__ == __main__:
  ll = (2.8,45.513,3.431,45.912)
  z = 10
  imgx = 542 * z
  imgy = 360 * z
  tiles = False
  tiles = True

  db=DB()
  if tiles:
m = Map(256,256, ll, bgColor='transparent')
  else:
m = Map(imgx,imgy,bgColor='#D9DADB',lonlat=ll)

  m.addPGLayer('cpborder', (select st_union(way) as way from planet_osm_polygon where \addr:postcode\ is not null group by \addr:postcode\) as roads, [line('red',2)])
  m.addPGLayer('cptext', (select way,\addr:postcode\ as name from planet_osm_polygon where \addr:postcode\ is not null) as roads, [text(13,'red','white',4)])

  if tiles:
mapfile='tiles_overlay.xml'
mapnik2.save_map(m.getMap(),mapfile)
render_tiles(ll, mapfile, 'tiles/',12,13)
  else:
m.zoomToBBox()
m.toPNG(cp.png)
  
  

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary=postal_code (était : admin_level = 9)

[Pieren]

2011/9/14 Christian Quest christian.qu...@gmail.com:
 A titre de test, j'ai créé les deux relations comme indiqué ici:
 http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010
 http://www.openstreetmap.org/browse/relation/1751952
 http://www.openstreetmap.org/browse/relation/1751953

Pourquoi avoir utiliser un tag postal_code:name et pourquoi avoir
utiliser une syntaxe différente pour le nom ? Dans OSM, on ne connait
pas la source de ton découpage, ni si c'est une source légale.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] HELP : wiki usages divers d'OSM

[ZIMMY]

Bonjour,

Je viens de créer un article complémentaire des exemple cartographiques
http://wiki.openstreetmap.org/wiki/FR:Cartotheque

Ici il s'agit de mettre en avant les utilisations qui vont servir pour le
lancement d'OSM France lorsque nous aurons besoin d'exemples 

http://wiki.openstreetmap.org/wiki/FR:Utilisations

Merci de me remonter les autres liens connus

Cordialement

ZIMMY

--
View this message in context: 
http://gis.638310.n2.nabble.com/HELP-wiki-usages-divers-d-OSM-tp6792678p6792678.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] HELP : wiki usages divers d'OSM

[Pieren]

Avant que tu viennes, il y avait déjà:

http://wiki.openstreetmap.org/wiki/FR:Autres_cartes_en_ligne
et
http://wiki.openstreetmap.org/wiki/FR:Sites_en_ligne_utilisant_OSM

Il vaudrait mieux améliorer les pages existantes au lieu de créer des
doublons à l'infini...

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary=postal_code (était : admin_level = 9)

[Christian Quest]

Le 14 septembre 2011 11:51, Pieren pier...@gmail.com a écrit :
 2011/9/14 Christian Quest christian.qu...@gmail.com:
 A titre de test, j'ai créé les deux relations comme indiqué ici:
 http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010
 http://www.openstreetmap.org/browse/relation/1751952
 http://www.openstreetmap.org/browse/relation/1751953

 Pourquoi avoir utiliser un tag postal_code:name et pourquoi avoir
 utiliser une syntaxe différente pour le nom ? Dans OSM, on ne connait
 pas la source de ton découpage, ni si c'est une source légale.


postal_code:name m'a semblé plus adapté que name car c'est le nom
du bureau distributeur attaché au code postal et rien d'autre. Sur cet
exemple, La Varenne St Hilaire n'a aucune existence administrative à
ce que je sache, c'est le nom d'un ancien village disparu depuis 1791
!

Pour la source, c'est juste un test et j'ai tracé aux limites que je
connais à peu près (après 45 ans passés dans la commune) puis en
testant les adresses une à une sur la frontière. On peut dire que
c'est 99,9% knowledge et 0,1% l'utilisation du formulaire en ligne
que j'ai cité (2 pâtés de maison au sud et un au nord).

Comment obtenir l'information légalement dans ce genre de cas assez
particuliers ?

Tiens, si j'allais demandé au bureau de poste principal (94100)...
c'est juste au bout de ma rue !

-- 
Christian

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] HELP : wiki usages divers d'OSM

[ZIMMY]

Bon merci de l'observation. Je vais donc compléter et replacer au bon
endroit.

ZIMMY

--
View this message in context: 
http://gis.638310.n2.nabble.com/HELP-wiki-usages-divers-d-OSM-tp6792678p6792869.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] [OSM Talk-fr] Parking Day

[RatZilla$]

Bonjour @tou[te]s,

Vendredi se tiendra dans le monde et à Paris le Parking Day
http://parkingday.org/.
Qui est dispo pour participer à l'évènement sur Paris en présentant les
possibilités d'OSM dans ce type d'évènement.
Contacter Nathanaël Sorin-Richez nathan...@siliconsentier.org pour les
détails de l'organisation de la journée.

Gaël
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary=postal_code (était : admin_level = 9)

[Pieren]

2011/9/14 Christian Quest christian.qu...@gmail.com:
 Le 14 septembre 2011 11:51, Pieren pier...@gmail.com a écrit :

 postal_code:name m'a semblé plus adapté que name car c'est le nom
 du bureau distributeur attaché au code postal et rien d'autre. Sur cet
 exemple, La Varenne St Hilaire n'a aucune existence administrative à
 ce que je sache, c'est le nom d'un ancien village disparu depuis 1791
 !

Pourtant, c'est toi qui a envoyé le lien vers cette page du wiki:
http://wiki.openstreetmap.org/wiki/Postal_code

qui précise
type=multipolygon
boundary=postal_code
name=optional - der Name des PLZ-Gebiets

On donne bien le nom d'une région postale, rien d'autre.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary=postal_code (était : admin_level = 9)

[Pieren]

2011/9/14 Pieren pier...@gmail.com:

Désolé, mauvais lien:
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary=postal_code (était : admin_level = 9)

[Christian Quest]

Le 14 septembre 2011 17:07, Pieren pier...@gmail.com a écrit :
 2011/9/14 Christian Quest christian.qu...@gmail.com:
 Le 14 septembre 2011 11:51, Pieren pier...@gmail.com a écrit :

 postal_code:name m'a semblé plus adapté que name car c'est le nom
 du bureau distributeur attaché au code postal et rien d'autre. Sur cet
 exemple, La Varenne St Hilaire n'a aucune existence administrative à
 ce que je sache, c'est le nom d'un ancien village disparu depuis 1791
 !

 Pourtant, c'est toi qui a envoyé le lien vers cette page du wiki:

http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010

 qui précise
 type=multipolygon
 boundary=postal_code
 name=optional - der Name des PLZ-Gebiets

 On donne bien le nom d'une région postale, rien d'autre.


Oui oui, je sais, mais à force d'utiliser name à toutes les sauces, ça met
un foutoir dans la majorité des rendus (oui, je sais aussi qu'on ne taggue
pas pour le rendu).

D'ailleurs, dans la traduction partielle en anglais qui se trouve en bas de
cette page du wiki, il est indiqué *optional - the name of the postal code
area if it has one. If multiple postal code areas have the same name, it
might make sense to include the post code itself in this name even though it
is superfluous.
'better: use note= instead of name=. The so tagged relations still are
distinguishable in the relation editor (this is the main reason for using
name=* in the german part of this page). The advantage of using note= is
that there won't be a rendering of names of virtual objects somewhere on the
map.*

note= me semble inadapté, car il s'agit bien d'un nom et pas d'une note mais
d'un nom de bureau distributeur lié au code postal d'où mon postal_code:name
et pas du nom du multipolygone.

Il y a peut être mieux que postal_code:name, c'est juste une proposition et
histoire de lancer la réflexion sur ce sujet.

-- 
Christian
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Appel à volontaire pour un mapping d'intérieur

[RatZilla$]

Salut Thomas ça coïncide avec le FOSDEM 2012 d'après ton lien !
Ce n'est pas plutôt ce lien là ?
http://at2011.agiletour.org/fr/at2011_lille.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary=postal_code (était : admin_level = 9)

[Ab_fab]

Selon l'Union Postale Universelle [1], c'est l'ARCEP [2] qui régule les
questions postales en France.

Selon le code des Postes et Télécommunications Electroniques, l'accès à
l'info géographique est possible à condition d'avoir une licence pour
effectuer les services postaux
Articles L3 et L3-1 [3]

[1] http://www.upu.int/fr/lupu/pays-membres/europe-occidentale/france.html
[2] http://www.arcep.fr
[3]
http://www.legifrance.gouv.fr/affichCode.do;jsessionid=284D09ACF81FF7DB2CC3DB09DCFBAC57.tpdjo05v_2?idSectionTA=LEGISCTA06136616cidTexte=LEGITEXT06070987dateTexte=20110914

Le 14 septembre 2011 17:05, JonathanMM jonatha...@nocle.fr a écrit :

 Le 14/09/2011 11:51, Pieren a écrit :
 
  Dans OSM, on ne connait pas la source de ton découpage, ni si c'est une
 source légale.
 J'y pense, avec l'ouverture à la concurrence des services postaux, il
 doit bien exister une autorité publique qui surveille tout ça et qui
 doit également avoir une BDD avec l'ensemble des codes postaux. Histoire
 qu'on se retrouve pas tous avec un code par entreprise :)
 On pourrait leur demander, non ?
 JonathanMM

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary=postal_code (était : admin_level = 9)

[Pieren]

2011/9/14 Christian Quest christian.qu...@gmail.com:
 oui, je sais aussi qu'on ne taggue pas pour le rendu

Ben, pourtant, c'est bien le cas. On ne taggue pas non plus pour le
relation editor de JOSM. Depuis le début, on utilise le tag name
pour désigner les noms des choses. Est-ce trop simple pour certains ?
Si Mapnik affiche tous les tags name sans faire le tri, ni regarder
avec quels autres tags il est combiné, c'est bien un problème de
rendu.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] HELP : wiki usages divers d'OSM

[Pieren]

Dans la série doublon, je continue avec cette page du wiki:
http://wiki.openstreetmap.org/wiki/FR:Using_OpenStreetMap

qui est aussi le 1er lien depuis [[FR:Page principale]] sous la
rubrique Découvrir OpenStreetMap.

Cette page gagnerait à être mise à jour, et pourquoi pas en adaptant
son équivalente en allemand qui à l'air d'être la plus aboutie:
http://wiki.openstreetmap.org/wiki/DE:Using_OpenStreetMap

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Appel à volontaire pour un mapping d'intérieur

[Thomas Clavier]

Le 14/09/2011 17:37, RatZilla$ a écrit :
 Salut Thomas ça coïncide avec le FOSDEM 2012 d'après ton lien !
 Ce n'est pas plutôt ce lien là ?
 http://at2011.agiletour.org/fr/at2011_lille.html


Alors je le refais avec le bon liens :
http://www.openstreetmap.org/?mlat=50.63329mlon=3.02004zoom=17
et oui c'est pour faire une belle carte pour l'agile tour 2011 :-)

-- 
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk/mail :   t...@tcweb.org
+33 (0)6 20 81 81 30   +33 (0)950 783 783




signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-ja] OSC2011東京秋

[ribbon]

On Wed, Sep 14, 2011 at 12:15:50PM +0900, Shu Higashi wrote:

  OSC会場近辺でOSMFJの年次総会を開催予定ということならば、
  11/19にセミナーを申し込んでおけばよいですね。
 
 総会は２〜３時間だと思っています。
 11/20は遠方から日帰りで来られる方もおられるのではと思い
 セミナーと懇親会の日程は迷っておりました。

OSCセミナー会場の余裕があれば、その場で総会、という
手もあるのですが、無理かなあ。

oota

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] OSC2011東京秋

[ribbon]

On Wed, Sep 14, 2011 at 02:29:50PM +0900, Tomomichi Hayakawa wrote:

 今回のOSC東京の会場は、ちょっと遠いところのようですので、
 11/19から一泊は覚悟しています。場合によっては、11/18から上京するかもです。
 今のところ、まだ、そんな感じの予定です。

東京駅からだと1時間以上かかります。
泊まるとなると、立川になるかと思います。

oota

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] OSC2011東京秋

[Tomomichi Hayakawa]

Tomです。

 東京駅からだと1時間以上かかります。
 泊まるとなると、立川になるかと思います。

前回、前々回と、高幡不動のホテルに泊まりましたが、
たぶん、今回もそのあたりかな。


2011/9/15 ribbon o...@ns.ribbon.or.jp:
 On Wed, Sep 14, 2011 at 02:29:50PM +0900, Tomomichi Hayakawa wrote:

 今回のOSC東京の会場は、ちょっと遠いところのようですので、
 11/19から一泊は覚悟しています。場合によっては、11/18から上京するかもです。
 今のところ、まだ、そんな感じの予定です。

 東京駅からだと1時間以上かかります。
 泊まるとなると、立川になるかと思います。

 oota

 ___
 Talk-ja mailing list
 Talk-ja@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ja


___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] OSC2011東京秋

[Hiroshi Miura]

デンバーでの、OSMFの総会は、昼休みを使いました。
昼休みが、１２：３０−１４：００だったのですが、その時間のセッションの合間に
おこないました。
参考まで。
OSCは昼休みがないでしたっけ。

三浦

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja