Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich

[Michael von Glasow]

On 02/05/2011 06:09 PM, Richard Mann wrote:

On Sat, Feb 5, 2011 at 12:32 AM, Michael von Glasow
mich...@vonglasow.com  wrote:

if I may just comment on the relation: I would also use stop
rather than forward_stop and backward_stop for the roles since the
outward and return directions of a spoon route are somewhat hard to tell
apart. (Unless one stop in the loop is formally designated as the terminus
where services routinely end.)

You have to use forward_stop and backward_stop if you combine the two
directions in one relation, otherwise the same-named stop in the two
directions don't get combined on the line diagram.
You're probably right (though I haven't tried plotting spoon lines yet), 
when the same stop is served twice, the tool needs that information. 
stop works well for single-direction relations. Maybe it would be best 
to use forward_stop and backward_stop for the stops which are served 
in both directions and stop for the stops in the loop.


Then again, I'm wondering whether that's too much tagging for the 
renderer already. Couldn't a well-written renderer look at the stop 
names and deduct from these the fact that the stop is the same? Or can 
you think of any case in which that wouldn't work?

I think if you use
two relations, one for each direction, it combines them regardless of
role (and even if there's no role).
I did a lot of experimenting to get a simple, one-relation-per-direction 
line to render correctly. If I remember that correctly, the stop role 
is required (forward_stop, backward_stop or platform will also 
work). The tags on the members also seem to matter (e.g. 
amenity=bus_station, even with the correct role, does not get rendered.)


Michael

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

Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich

[Richard Mann]

On Sun, Feb 6, 2011 at 11:23 PM, Michael von Glasow
mich...@vonglasow.com wrote:
 I did a lot of experimenting to get a simple, one-relation-per-direction
 line to render correctly. If I remember that correctly, the stop role is
 required (forward_stop, backward_stop or platform will also work). The
 tags on the members also seem to matter (e.g. amenity=bus_station, even with
 the correct role, does not get rendered.)

http://www.openstreetmap.org/browse/relation/34631 doesn't have roles
on the nodes (and it's one of the two relations used for the working
example on http://78.46.81.38/public_transport.html ).

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

Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich

[Dominik Mahrer (Teddy)]

On 02/07/2011 12:23 AM, Michael von Glasow wrote:

On 02/05/2011 06:09 PM, Richard Mann wrote:

On Sat, Feb 5, 2011 at 12:32 AM, Michael von Glasow
mich...@vonglasow.com wrote:

if I may just comment on the relation: I would also use stop
rather than forward_stop and backward_stop for the roles since the
outward and return directions of a spoon route are somewhat hard to tell
apart. (Unless one stop in the loop is formally designated as the
terminus
where services routinely end.)

You have to use forward_stop and backward_stop if you combine the two
directions in one relation, otherwise the same-named stop in the two
directions don't get combined on the line diagram.

You're probably right (though I haven't tried plotting spoon lines yet),
when the same stop is served twice, the tool needs that information.
stop works well for single-direction relations. Maybe it would be best
to use forward_stop and backward_stop for the stops which are served
in both directions and stop for the stops in the loop.


I did not play around with actual renderers, but in theory the renderer 
should be able to get the diagram out of the order of the stops, 
regardless of the role. If one stop is twice in the route relation it 
should be obvious that it has to be some kind of loop. So in theory 
forward_stop and backward_stop can be replaced by the role stop.


Or did I miss something?

Teddych

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

[talk-ph] mapquest now with global routing

[maning sambale]

I don't know if this was posted before, but mapquest now has global
routing enabled.
http://www10.giscafe.com/nbc/articles/view_article.php?articleid=919733utm_source=twitterfeedutm_medium=statusnet

A test here Marikina to Cebu:
http://open.mapquest.com/link/9-D3nY6m7C



-- 
cheers,
maning
--
Freedom is still the most radical idea of all -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--

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

Re: [OSM-talk-be] huisnummers

[Ivo De Broeck]

Prima gedaan. Kan ook zo
http://www.openstreetmap.org/?lat=50.82862lon=4.74559zoom=17

Op 6 februari 2011 19:35 schreef Karel Adams ade...@skynet.be het
volgende:

 Nu het toch zo stillekes is, heb ik me uiteindelijk toegelegd op een punt
 dat me al lang fascineerde: huisnummers. Ik heb een voorzichtige poging
 gedaan hier rondom mijn eigen woning, en zou daarop graag kritiek krijgen,
 uiteraard enkel opbouwend.. };-)
 Inspiratie vond ik in Antwerpen, omstreeks de Ossenmarkt; er schijnt
 daaromtrent een specialist te wonen...
 Bij voorbaat dankend,
 KA

 http://www.openstreetmap.org/?lat=51.014334lon=4.334795zoom=18layers=M

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




-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] huisnummers

[Luc Van den Troost]

De 'methode met de lijn' zoals ook door Karel toegepast is de makkelijkste
en de snelste. Zeker waar de nummers nogal 'gelijkmatig verspreid' zijn en
wat logica volgen.

Elk huis individueel tekenen en het huiste huisnummer toekennen is uiteraard
precieser, maar wel veel werk.

Moesten we van alle straten en tussen alle kruispunten de nummers
even/oneven al in OSM hebben, het zou al mooi zijn... Eens we alle gebouwen
en individuele huisnummers hebben is het natuurlijk nog mooier...

Het meest nuttig zijn huisnummers in praktijk nog waar je lange straten hebt
met eenrichtingstoestanden, eventueel nog verschillende richtingen voor even
en oneven en nog een boel 'restricties'. Bijvoorbeeld toestanden zoals hier
op de Italielei waar de huisnummers alleen op de zijrijbanen zijn, die
bovendien enkele richting zijn en tegengesteld aan mekaar. Het maakt daarbij
nogal een verschil of je bv. nummer 80 of nummer 81 zoekt, en de route
ernaartoe zou ook helemaal anders zijn.

Hier kom ik de laatste tijd niet veel meer aan mappen toe, aangezien de
nakende verhuis naar München nu meer in mn kop zit en ook nogal wat tijd in
beslag neemt...

Luc / Speedy

2011/2/6 Ivo De Broeck ivo.debro...@gmail.com

 Prima gedaan. Kan ook zo
 http://www.openstreetmap.org/?lat=50.82862lon=4.74559zoom=17

 Op 6 februari 2011 19:35 schreef Karel Adams ade...@skynet.be het
 volgende:

 Nu het toch zo stillekes is, heb ik me uiteindelijk toegelegd op een punt
 dat me al lang fascineerde: huisnummers. Ik heb een voorzichtige poging
 gedaan hier rondom mijn eigen woning, en zou daarop graag kritiek krijgen,
 uiteraard enkel opbouwend.. };-)
 Inspiratie vond ik in Antwerpen, omstreeks de Ossenmarkt; er schijnt
 daaromtrent een specialist te wonen...
 Bij voorbaat dankend,
 KA

 http://www.openstreetmap.org/?lat=51.014334lon=4.334795zoom=18layers=M

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




 --
 Ivo De Broeck
 Valleilaan 13
 3360  Korbeek-lo
 Tel (0)16 43 84 93
 Gsm +32 486 17 61 13

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


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

Re: [OSM-legal-talk] Contributor Terms upgrade ready

[Olaf Schmidt-Wischhöfer]

Hi,

Kai described my concern with the currect CT wording very well.
Is the LWG still working on a reply?

I am asking because if the LWG is convinced that there is no problem, then we 
need to explain our concern is better words.

Olaf

 OSMF can't force you to accept them, but if you don't, you loose your
 active contributor status and thus your right to vote.
 
 The free and open restriction probably still holds, but the vote does
 seem to be circumventable by the method suggested by Olaf, by including
 what you want to vote for in the new CT, then enforce those CT and finally
 vote, once only those are active contributors who have already agreed to
 the change through the new CT.
 
 Perhaps the vote can be extended to anyone who ever reached active
 contributor status and responds to a request to vote within 3 weeks
 assuming a reasonable effort has been undertaken to deliver the request to
 vote.
 
 Kai



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

Re: [OSM-talk] (magical?) road detector

[Steve Bennett]

On Sun, Feb 6, 2011 at 2:32 PM, Ido Omer ido.o...@microsoft.com wrote:
 It is not open at the moment.
 I am not so sure what is the policy and I'll sniff around... but I'm not sure 
 it will be very easy to do that.
 In any case, even if we get an approval to switch to open source, it will 
 probably take a few weeks of cleaning it up before we could do that.

Strange...so MS is willing to invest resources in developing a tool
which is useful to the open-source map community, and to actively
promote the tool to the open-source map community, but not
open-license the source itself?

But I guess I don't know much about what led to SteveC's original
announcement, or exactly what his role in MS is.

Steve

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

Re: [OSM-talk] (magical?) road detector

[Steve Bennett]

On Sun, Feb 6, 2011 at 1:01 PM, Thibault North tno...@fedoraproject.org wrote:
 In the mapping process (with JOSM or such tool), following roads is not really
 a problem, especially when they are not too sinuous (and that's when the road
 detector works well...). It can be done in a few clicks. Maybe the tool should
 try and act differently (but that is more GUI/UI related), and we could 
 imagine
 the following scenario:
 - The user wants to map roads and selects a road extraction tool.
 - He roughly follows a road, maintaining a click (as you would do to paint
 with a brush in image processing softwares)
 - The algorithm knows the approximate path, and tries to fit exactly the 
 center
 of the road.

I think this would be the best way to do it. If an editor could
perform each of the following operations with a single click or
keystroke:
- draw straight way segment from the last node to the mouse cursor
- draw from the last node to the mouse cursor, following a perceived road
- undo last automatically drawn section

Or perhaps even the following:
- advance from the last node a further X distance, following roads
(where X is dependent on zoom level)

...then you have the makings of a very efficient process for tracing
roads off imagery. The last operation above would let you keep hitting
a key to advance a road until something goes wrong, then backtrack and
fix it manually.

What I saw in my testing was that most of the time (perhaps 70%) it
got the road right, and sometimes it was just hopelessly wrong. That
is presumably because the algorithm is determined that there *is* a
road to find. It would be better for it to give up and not draw a road
at all if its confidence isn't high.

Steve

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

Re: [OSM-talk] (magical?) road detector

[Anthony]

Thanks Ido.  Even just a partial release would be great.  I'd love to
see this adapted to use non-Bing imagery, and something that could use
multiple image sources simultaneously would potentially be really
awesome.

On Sat, Feb 5, 2011 at 10:32 PM, Ido Omer ido.o...@microsoft.com wrote:
 It is not open at the moment.
 I am not so sure what is the policy and I'll sniff around... but I'm not sure 
 it will be very easy to do that.
 In any case, even if we get an approval to switch to open source, it will 
 probably take a few weeks of cleaning it up before we could do that.

 Ido

 -Original Message-
 From: dipie...@gmail.com [mailto:dipie...@gmail.com] On Behalf Of Anthony
 Sent: Saturday, February 05, 2011 6:47 PM
 To: Ido Omer
 Cc: talk@openstreetmap.org
 Subject: Re: [OSM-talk] (magical?) road detector

 On Fri, Feb 4, 2011 at 1:59 PM, Ido Omer ido.o...@microsoft.com wrote:
 I am a researcher at Microsoft and I am currently working on the road
 detector.

 Hi Ido.  The code to the road detector isn't at all open, is it?



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

[OSM-talk] OpenDEM - Free Digital Elevation Models and height data

[OpenDEM]

Hi,

 

OpenDEM is an open project for sharing the 3rd dimension of the earths
surface. Here you can find and share free digital elevation models and
height data (e.g. GPX tracks). 

 

The projects is available under: http://www.opendem.info
http://www.opendem.info/ 

 

Best regards,

 

Martin Over

 

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

Re: [OSM-talk] (magical?) road detector

[Ido Omer]

Hi Thibault,

Thanks again for your response.
I might be a bit overoptimistic, but I think the tool will be able to handle 
most cases as long as you use it properly.
We have preliminary nice results (internally) even in urban area and places 
with shadows etc. as long as you are detecting a reasonable road.
We don't believe the attached examples are typical examples. They are nice for 
demonstrating the limitations of the algorithm and computer vision techniques 
in general, but we don't think the average user will try to model a way that 
spans over a few roads with many junctions. In the examples you sent, it is not 
clear which is the road that connects the two points in question, since there 
are many valid possibilities between them.
We plan on having an exploration mode that will suggest many roads in the 
region; however, it will be based on a different module and will use different 
techniques.
I posted a (partial) list of the road detection algorithm's limitations. I am 
confident that once you apply them, you will find performance has improved.
There are also several modules that we have in house, and have already tested, 
but still have not incorporated in the road detection pipeline, for instance, 
car detector that can help a lot in dense urban areas.
As I stated earlier, Bing is not putting its full weight on trying to solve 
this problem, and our (development) resources are quite limited, but we at Bing 
believe that our effort will create value for the OSM community and help build 
better map editing tools.

Regards,
Ido

-Original Message-
From: Thibault North [mailto:tno...@fedoraproject.org] 
Sent: Saturday, February 05, 2011 6:02 PM
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] (magical?) road detector

A few remarks again below:

On February 5, 2011 06:57:42 pm Ido Omer wrote:
 Hi Elizabeth,
 
 Like in any interesting problem, we knew we will not be able to come 
 up with a general solution for all roads under any condition. We 
 assume most people are mapping asphalt/concrete roads and we decided 
 to focus our efforts there.

And even in that case, good luck! :-)
See for example these two shots from Bing maps, Montreal, and how bad is the 
road extraction:
http://tnorth.ch/blog/public/Dijkstra/tests/montreal1_out.jpg
http://tnorth.ch/blog/public/Dijkstra/tests/montreal2_out.jpg
(Showing, by the way, that a shortest-path algorithm is not always what we want 
to extract data in a robust way...)

Image processing in that area is a pain: shadows, trees over the road, gray 
roofs that look pretty much like a road...

 Eve there our solution is far from being perfect, but we believe in 
 most circumstances it has a value that is larger than zero.

I don't really know what to think about that. The tool will maybe never be 
efficient to handle most cases, but can perhaps sometimes help, and it is a 
sufficient reason to try and improve it.
Allowing the user to have some kind of control might help the detection to be 
done properly.

 Strictly speaking, the current version doesn't look for road patterns; 
 the next version might do that and provide a more general solution. It 
 will be useful for us to learn what the community needs are; I'll be 
 happy if you could refer me to a few examples.

In the mapping process (with JOSM or such tool), following roads is not really 
a problem, especially when they are not too sinuous (and that's when the road 
detector works well...). It can be done in a few clicks. Maybe the tool should 
try and act differently (but that is more GUI/UI related), and we could imagine 
the following scenario:
- The user wants to map roads and selects a road extraction tool.
- He roughly follows a road, maintaining a click (as you would do to paint with 
a brush in image processing softwares)
- The algorithm knows the approximate path, and tries to fit exactly the center 
of the road.

Regards,
Thibault

 BTW, by not using the detector its usefulness should be around zero, 
 it is hard for me to imagine how can it drop much lower than that (at 
 least for the long run, after you wasted a couple of minutes and found 
 out it does not serve your needs)
 
 Thanks,
 Ido
 
 -Original Message-
 From: Elizabeth Dodd [mailto:ed...@billiau.net]
 Sent: Saturday, February 05, 2011 2:27 PM
 To: talk@openstreetmap.org
 Subject: Re: [OSM-talk] (magical?) road detector
 
 I've made one attempt only at tracing a dirt road in dry country with 
 the detector. I found its usefulness less than zero, as the system 
 told me that too many tiles were involved and quit. Zooming in is not 
 always practical to spot these roads, where the pattern recognition is 
 a very long straight feature on a photograph, and same colour as the 
 surrounds for a dirt road in dry country, and a dark colour for a 
 railway. Having spotted the road then it is easier to find in zoomed 
 images when looking for curved bits through (dry) waterways. I went 
 back to doing it by hand, so for me 

Re: [OSM-talk] (magical?) road detector

[Ido Omer]

Hi Steve,

What we currently exposed is a web service that given two points finds the best 
road between them (or at least what it considers as best, which can be really 
bad sometimes)
We are not stopping people from using this service in their editors and achieve 
part of the functionality you suggested (we really hope this will happen).
We will add more functionality with time and are open to suggestions.

Thanks,
Ido


-Original Message-
From: Steve Bennett [mailto:stevag...@gmail.com] 
Sent: Sunday, February 06, 2011 2:19 AM
To: Thibault North
Cc: talk@openstreetmap.org
Subject: Re: [OSM-talk] (magical?) road detector

On Sun, Feb 6, 2011 at 1:01 PM, Thibault North tno...@fedoraproject.org wrote:
 In the mapping process (with JOSM or such tool), following roads is 
 not really a problem, especially when they are not too sinuous (and 
 that's when the road detector works well...). It can be done in a few 
 clicks. Maybe the tool should try and act differently (but that is 
 more GUI/UI related), and we could imagine the following scenario:
 - The user wants to map roads and selects a road extraction tool.
 - He roughly follows a road, maintaining a click (as you would do to 
 paint with a brush in image processing softwares)
 - The algorithm knows the approximate path, and tries to fit exactly 
 the center of the road.

I think this would be the best way to do it. If an editor could perform each of 
the following operations with a single click or
keystroke:
- draw straight way segment from the last node to the mouse cursor
- draw from the last node to the mouse cursor, following a perceived road
- undo last automatically drawn section

Or perhaps even the following:
- advance from the last node a further X distance, following roads (where X is 
dependent on zoom level)

...then you have the makings of a very efficient process for tracing roads off 
imagery. The last operation above would let you keep hitting a key to advance a 
road until something goes wrong, then backtrack and fix it manually.

What I saw in my testing was that most of the time (perhaps 70%) it got the 
road right, and sometimes it was just hopelessly wrong. That is presumably 
because the algorithm is determined that there *is* a road to find. It would be 
better for it to give up and not draw a road at all if its confidence isn't 
high.

Steve

___
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] (magical?) road detector

[Anthony]

On Sun, Feb 6, 2011 at 2:40 PM, Ido Omer ido.o...@microsoft.com wrote:
 Hi Steve,

 What we currently exposed is a web service that given two points finds the 
 best road
 between them (or at least what it considers as best, which can be really bad 
 sometimes)
 We are not stopping people from using this service in their editors and 
 achieve part of the
 functionality you suggested (we really hope this will happen).

What are the restrictions on the use of the API?  Are we allowed to
store results?  Compare them with other data (LIDAR, parcel data, USGS
imagery)?  Access it by bot without human intervention?

Even without the source code, I can think of a lot of neat things that
can be done with the API.  But I'm not sure they're consistent with
the intent for which the service was released.

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

Re: [OSM-talk] (magical?) road detector

[Thibault North]

Hi Ido,

Of course, the attached pictures and their long path are not a typical use 
case, but they show how easy it is to make the automatic extraction of a road 
network difficult.
And as it has been mentioned here, the mapping of small road portions is 
already quite easy to do, and an automatic tool would be interesting only if 
it can provide more than that: that would certainly attract more people.

Anyway, it will be interesting to see how better this service will do in a 
near future.

Thanks,
Thibault 

On February 6, 2011 02:32:01 pm you wrote:
 Hi Thibault,
 
 Thanks again for your response.
 I might be a bit overoptimistic, but I think the tool will be able to
 handle most cases as long as you use it properly. We have preliminary nice
 results (internally) even in urban area and places with shadows etc. as
 long as you are detecting a reasonable road. We don't believe the
 attached examples are typical examples. They are nice for demonstrating
 the limitations of the algorithm and computer vision techniques in
 general, but we don't think the average user will try to model a way that
 spans over a few roads with many junctions. In the examples you sent, it
 is not clear which is the road that connects the two points in question,
 since there are many valid possibilities between them. We plan on having
 an exploration mode that will suggest many roads in the region; however,
 it will be based on a different module and will use different techniques.
 I posted a (partial) list of the road detection algorithm's limitations. I
 am confident that once you apply them, you will find performance has
 improved. There are also several modules that we have in house, and have
 already tested, but still have not incorporated in the road detection
 pipeline, for instance, car detector that can help a lot in dense urban
 areas. As I stated earlier, Bing is not putting its full weight on trying
 to solve this problem, and our (development) resources are quite limited,
 but we at Bing believe that our effort will create value for the OSM
 community and help build better map editing tools.
 
 Regards,
 Ido
 
 -Original Message-
 From: Thibault North [mailto:tno...@fedoraproject.org]
 Sent: Saturday, February 05, 2011 6:02 PM
 To: talk@openstreetmap.org
 Subject: Re: [OSM-talk] (magical?) road detector
 
 A few remarks again below:
 
 On February 5, 2011 06:57:42 pm Ido Omer wrote:
  Hi Elizabeth,
  
  Like in any interesting problem, we knew we will not be able to come
  up with a general solution for all roads under any condition. We
  assume most people are mapping asphalt/concrete roads and we decided
  to focus our efforts there.
 
 And even in that case, good luck! :-)
 See for example these two shots from Bing maps, Montreal, and how bad is
 the road extraction:
 http://tnorth.ch/blog/public/Dijkstra/tests/montreal1_out.jpg
 http://tnorth.ch/blog/public/Dijkstra/tests/montreal2_out.jpg
 (Showing, by the way, that a shortest-path algorithm is not always what we
 want to extract data in a robust way...)
 
 Image processing in that area is a pain: shadows, trees over the road, gray
 roofs that look pretty much like a road...
 
  Eve there our solution is far from being perfect, but we believe in
  most circumstances it has a value that is larger than zero.
 
 I don't really know what to think about that. The tool will maybe never be
 efficient to handle most cases, but can perhaps sometimes help, and it is
 a sufficient reason to try and improve it. Allowing the user to have some
 kind of control might help the detection to be done properly.
 
  Strictly speaking, the current version doesn't look for road patterns;
  the next version might do that and provide a more general solution. It
  will be useful for us to learn what the community needs are; I'll be
  happy if you could refer me to a few examples.
 
 In the mapping process (with JOSM or such tool), following roads is not
 really a problem, especially when they are not too sinuous (and that's
 when the road detector works well...). It can be done in a few clicks.
 Maybe the tool should try and act differently (but that is more GUI/UI
 related), and we could imagine the following scenario: - The user wants to
 map roads and selects a road extraction tool. - He roughly follows a
 road, maintaining a click (as you would do to paint with a brush in image
 processing softwares) - The algorithm knows the approximate path, and
 tries to fit exactly the center of the road.
 
 Regards,
 Thibault
 
  BTW, by not using the detector its usefulness should be around zero,
  it is hard for me to imagine how can it drop much lower than that (at
  least for the long run, after you wasted a couple of minutes and found
  out it does not serve your needs)
  
  Thanks,
  Ido
  
  -Original Message-
  From: Elizabeth Dodd [mailto:ed...@billiau.net]
  Sent: Saturday, February 05, 2011 2:27 PM
  To: talk@openstreetmap.org
  Subject: Re: [OSM-talk] (magical?) 

Re: [OSM-talk] (magical?) road detector

[Stephan Knauss]

On 06.02.2011 21:14, Anthony wrote:

What are the restrictions on the use of the API?  Are we allowed to
store results?


I'm not a lawyer, but the current TOU seam not to allow it to be used in 
our editors.


It says use in a non-commercial editor application of OpenStreetMap maps

JOSM is GPL. That is not non-commercial.
Merkaator is GPL. That is not non-commercial.
Potlatch (2) is GPL. That is not non-commercial.
Mapzen is GPL. That is not non-commercial.

Did Bing want to say it's not allowed to charge users for the 
possibility to use the API? Or it's not allowed to pay users for tracing 
roads using this API? Then you should write it like this.


Stephan

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

Re: [OSM-talk] (magical?) road detector

[Richard Fairhurst]

Stephan Knauss wrote:
 I'm not a lawyer, but the current TOU seam not to allow it to be used 
 in our editors.

My understanding of this Bing term is that it's _intended_ to mean not
available for use in an editor that is only available under commercial
terms, e.g. the ArcGIS plugin. I agree there's ambiguity there and clearing
up the NC terms was one of the suggestions I made for clarifying the licence
(suggestions which are currently with OSMF on the way to Bing, I believe).

 Potlatch (2) is GPL. That is not non-commercial.

No it fricking isn't GPL!

Potlatch 2 is proudly WTFPL:
http://svn.openstreetmap.org/applications/editors/potlatch2/LICENCE.txt

cheers
Richard


-- 
View this message in context: 
http://gis.638310.n2.nabble.com/magical-road-detector-tp5993637p5998722.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] (magical?) road detector

[Stephan Knauss]

On 07.02.2011 00:05, Richard Fairhurst wrote:

Stephan Knauss wrote:

I'm not a lawyer, but the current TOU seam not to allow it to be used
in our editors.

My understanding of this Bing term is that it's _intended_ to mean not
available for use in an editor that is only available under commercial
terms, e.g. the ArcGIS plugin.


That's also what I assume, but the written text could mean something else.


Potlatch (2) is GPL. That is not non-commercial.

Potlatch 2 is proudly WTFPL:
http://svn.openstreetmap.org/applications/editors/potlatch2/LICENCE.txt


Oh, I was tricked by the wiki page stating it's GPL...
http://wiki.openstreetmap.org/wiki/Potlatch2

Stephan


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

Re: [OSM-talk] (magical?) road detector

[Richard Fairhurst]

Stephan Knauss wrote:
 Oh, I was tricked by the wiki page stating it's GPL...
 http://wiki.openstreetmap.org/wiki/Potlatch2

Wow. Who on earth added that?

cheers
Richard


-- 
View this message in context: 
http://gis.638310.n2.nabble.com/magical-road-detector-tp5993637p5998760.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] (magical?) road detector

[David Murn]

On Sun, 2011-02-06 at 15:33 -0800, Richard Fairhurst wrote:
 Stephan Knauss wrote:
  Oh, I was tricked by the wiki page stating it's GPL...
  http://wiki.openstreetmap.org/wiki/Potlatch2
 
 Wow. Who on earth added that?

You mean, as author of potlatch, you dont have the potlatch wiki page on
watch for edits?  I also notice the edit you made, removed the entire
software info block from the wiki page, not just changed the licence.
Was that intentional?

David


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

Re: [OSM-talk] (magical?) road detector

[Ido Omer]

I'm not a lawyer either and I don't want to get myself into more trouble than 
necessary, but as far as I know, as long as it is a non-commercial editor, 
using the API should be OK.
I'll try to find out what exactly are the exact limitations on using the API.

Regarding other sources of data, we are definitely going to use all available 
data sources. I don't see a reason not to use other types of data. Trying to 
solve the problem using computer vision alone is way too ambitious. The only 
problem with using different sources of data is probably making sure the 
sources are well aligned/registered (which is not a trivial problem).


-Original Message-
From: dipie...@gmail.com [mailto:dipie...@gmail.com] On Behalf Of Anthony
Sent: Sunday, February 06, 2011 12:15 PM
To: Ido Omer
Cc: Steve Bennett; talk@openstreetmap.org
Subject: Re: [OSM-talk] (magical?) road detector

On Sun, Feb 6, 2011 at 2:40 PM, Ido Omer ido.o...@microsoft.com wrote:
 Hi Steve,

 What we currently exposed is a web service that given two points finds 
 the best road between them (or at least what it considers as best, 
 which can be really bad sometimes) We are not stopping people from 
 using this service in their editors and achieve part of the functionality you 
 suggested (we really hope this will happen).

What are the restrictions on the use of the API?  Are we allowed to store 
results?  Compare them with other data (LIDAR, parcel data, USGS imagery)?  
Access it by bot without human intervention?

Even without the source code, I can think of a lot of neat things that can be 
done with the API.  But I'm not sure they're consistent with the intent for 
which the service was released.


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

[OSM-talk] osm new zealand website and community launch

[Robin Paulson]

Hi all,
OSM New Zealand have recently launched their website, and announced
meetings beginning this month:
http://www.openstreetmap.org.nz/
http://wiki.openstreetmap.org/wiki/WikiProject_New_Zealand#OSM_Auckland_meetings

Other than this list, is there any particular place in the world of
osm where it would be useful to announce this?

How do i get meetings included in the wiki front page?

Cheers

-- 
Robin

http://tangleball.org.nz/ - Auckland's Creative Space
http://bumblepuppy.org/blog/

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

Re: [OSM-talk] osm new zealand website and community launch

[Richard Weait]

On Sun, Feb 6, 2011 at 10:43 PM, Robin Paulson robin.paul...@gmail.com wrote:

 How do i get meetings included in the wiki front page?

1) Log in to the wiki.  The wiki account is separate from your api account.
2) Add your event to the wiki calendar.  [1]


[1] http://wiki.openstreetmap.org/index.php?title=Template:Calendaraction=edit

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

Re: [OSM-talk] (magical?) road detector

[Richard Fairhurst]

David Murn wrote:

You mean, as author of potlatch


Only one of the authors.


you dont have the potlatch wiki page on watch for edits? I also
notice the edit you made, removed the entire software info block from
the wiki page, not just changed the licence. Was that intentional?


Yep. Way too many inaccuracies: wrong licence, citing just two of 
several authors, citing just one of several URLs were the ones I spotted 
at a cursory glance.


If the authors would like to do five minutes of research and put some 
correct info back that's great - or, alternatively, they could mail the 
potlatch-dev@ list and ask for assistance. But this kind of oh, let's 
just put some unchecked info up is why so many people disregard the 
wiki these days. We wouldn't tolerate anything so disconnected from 
reality on the map, and nor should we on the wiki.


cheers
Richard


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

[OSM-talk-nl] Nederlandse mapnik renderer stuk?

[Martien Scheepens]

Hallo iedereen,

Het viel me op dat mijn wijzigingen sinds vrijdag niet meer op de
Nederlandse server zichtbaar worden (Geld voor Speed- en LiveLayer), op de
internationale kaart was de wijziging met TAH en mapnik binnen het uur
zichtbaar. Staat de renderer uit?
Bijgesloten is een voorbeeld van een edit (van vrijdag) die nog niet
verwerkt is: [url=
http://tile.openstreetmap.nl/?zoom=17lat=53.01036lon=6.75056layers=0B0]VerkeerspleinGieten
in Drenthe[/url]. Ik heb ook de laatste wijzigingen van DTeelde en
noordfiets bekeken en ook hun wijzigingen zijn alleen maar in de
internationale versie zichtbaar. Ook heb ik met de Duitser de plekken
bekeken (rendert on-demand, omdat niemand met de Duitse kaart NL bekijkt) en
dan zijn de wijzigingen ook zichtbaar.
Tot dusver mijn verhaal. Zijn er technische problemen?

Groeten,

Martien

__

Dit bericht is op de mailinglijst en op het forum geplaatst.
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [talk-au] Relicensing per changeset?

[Andrew Gregory]

On 5 February 2011 21:35, Stephen Hope slh...@gmail.com wrote:


 Well, yes.  This is one reason I've stopped putting data in, if I
 don't know the original source of the ways I'm working on.  If you
 want to be sure your changes can be kept, and you know the original
 way is bad, you could delete it entirely and draw your own.


Well, then what I'll do is download the areas in JOSM, save them as OSM
files and stash them. Then if where I've been is wiped out I'll have
something saved to merge in or refer to at least. If nothing else I still
have MBs of photos of street signs!

I just don't understand why data I've marked survey would be deleted. I
mean, I'd be surprised if there aren't some ways I've traced from Nearmaps
but unintentionally forgot to source. If those are going to be trusted, why
not stuff explicitly surveyed? Bah - sorry for grumbling.

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

Re: [talk-au] Relicensing per changeset?

[4x4falcon]

Well, then what I'll do is download the areas in JOSM, save them as OSM
files and stash them. Then if where I've been is wiped out I'll have
something saved to merge in or refer to at least. If nothing else I
still have MBs of photos of street signs!




Good idea but it will also be in fosm.org already and will stay there 
after any deletion from osm.


Plus there are several others storing full planet files for after any 
deletion date.


Cheers
Ross

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

[Talk-br] iniciante: dúvida

[rodrigo goncalves]

Olá pessoal,
esta é minha primeira mensagem para o grupo que já venho acompanhando há
alguns dias. Sou geógrafo e trabalho com software (linux, win) e tenho
especial apreço por mapas. Descobrir esse projeto foi um grande achado do
ano passado.

Ainda não me interei nas contribuições pois não tenho um GPS, mas espero
poder contribuir do lado dos sistemas que se utilizam a base do OSM. Estou
baixando o Mapnik e quero ver se consigo ao menos exportar alguma coisa.

Mas o objetivo desta mensagem é fazer uma pergunta à comunidade. Localizei
um ponto em três bases de mapas (Google Maps, Bing Maps, OSM) e em todas
elas a pequena viela que queria o nome não está cadastrada. Trata-se de uma
viela na cidade velha de Hastings, no litoral inglês. Estou geo-tagueando
algumas fotos antigas e gostaria de especificar certinho o nome da rua.

A pergunta é a seguinte: tem como eu saber quem ou qual grupo de usuários
mapeou a região? Pensei que entrar em contato com o equivalente ao talk-br
para aquela região e lançar a pergunta àquela comunidade. O permalink para a
área é 
estehttp://www.openstreetmap.org/?lat=50.857708lon=0.590046zoom=18layers=M.
Como ter acesso a essa informação sobre a origem dos dados daquela área?

Obrigado e abraço a todos que contribuem com o projeto,
Rodrigo
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] iniciante: dúvida

[Ronaldo Maia]

Vc pode clicar na opção '+' no canto direito superior do mapa,
Selecionar para exibir o layer dos dados.

As vezes ele não exibe pois a área é muito grande, Depois disso, pode
selecionar o objeto que quer ver mais detalhes, e clicar para exibir
os detalhes ou histórico

[]s

2011/2/6 rodrigo goncalves goncalves.rodrigo...@gmail.com:
 Olá pessoal,
 esta é minha primeira mensagem para o grupo que já venho acompanhando há
 alguns dias. Sou geógrafo e trabalho com software (linux, win) e tenho
 especial apreço por mapas. Descobrir esse projeto foi um grande achado do
 ano passado.
 Ainda não me interei nas contribuições pois não tenho um GPS, mas espero
 poder contribuir do lado dos sistemas que se utilizam a base do OSM. Estou
 baixando o Mapnik e quero ver se consigo ao menos exportar alguma coisa.
 Mas o objetivo desta mensagem é fazer uma pergunta à comunidade. Localizei
 um ponto em três bases de mapas (Google Maps, Bing Maps, OSM) e em todas
 elas a pequena viela que queria o nome não está cadastrada. Trata-se de uma
 viela na cidade velha de Hastings, no litoral inglês. Estou geo-tagueando
 algumas fotos antigas e gostaria de especificar certinho o nome da rua.
 A pergunta é a seguinte: tem como eu saber quem ou qual grupo de usuários
 mapeou a região? Pensei que entrar em contato com o equivalente ao talk-br
 para aquela região e lançar a pergunta àquela comunidade. O permalink para a
 área é este. Como ter acesso a essa informação sobre a origem dos dados
 daquela área?
 Obrigado e abraço a todos que contribuem com o projeto,
 Rodrigo
 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-br





-- 
Ronaldo Maia

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

Re: [Talk-br] iniciante: dúvida

[rodrigo goncalves]

Perfeito. Já consegui achar o usuário que inseriu os dados.
Abs!

2011/2/6 Ronaldo Maia rom...@async.com.br

 Vc pode clicar na opção '+' no canto direito superior do mapa,
 Selecionar para exibir o layer dos dados.

 As vezes ele não exibe pois a área é muito grande, Depois disso, pode
 selecionar o objeto que quer ver mais detalhes, e clicar para exibir
 os detalhes ou histórico

 []s

 2011/2/6 rodrigo goncalves goncalves.rodrigo...@gmail.com:
  Olá pessoal,
  esta é minha primeira mensagem para o grupo que já venho acompanhando há
  alguns dias. Sou geógrafo e trabalho com software (linux, win) e tenho
  especial apreço por mapas. Descobrir esse projeto foi um grande achado do
  ano passado.
  Ainda não me interei nas contribuições pois não tenho um GPS, mas espero
  poder contribuir do lado dos sistemas que se utilizam a base do OSM.
 Estou
  baixando o Mapnik e quero ver se consigo ao menos exportar alguma coisa.
  Mas o objetivo desta mensagem é fazer uma pergunta à comunidade.
 Localizei
  um ponto em três bases de mapas (Google Maps, Bing Maps, OSM) e em todas
  elas a pequena viela que queria o nome não está cadastrada. Trata-se de
 uma
  viela na cidade velha de Hastings, no litoral inglês. Estou geo-tagueando
  algumas fotos antigas e gostaria de especificar certinho o nome da rua.
  A pergunta é a seguinte: tem como eu saber quem ou qual grupo de usuários
  mapeou a região? Pensei que entrar em contato com o equivalente ao
 talk-br
  para aquela região e lançar a pergunta àquela comunidade. O permalink
 para a
  área é este. Como ter acesso a essa informação sobre a origem dos dados
  daquela área?
  Obrigado e abraço a todos que contribuem com o projeto,
  Rodrigo
  ___
  Talk-br mailing list
  Talk-br@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-br
 
 



 --
 Ronaldo Maia

 ___
 Talk-br mailing list
 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] Wieviel Bäume sind ein Wald - Uferbäume

[Steffen Heinz]

Am 05.02.2011 22:43, schrieb M∡rtin Koppenhoefer:

http://urts55.uni-trier.de:8080/Projekte/WBB2009/DWB/wbgui_py?lemid=GA1

nachlesen. M.E. ist Hecke in OSM genau das, was es sprachlich auch
bedeutet: ein lineares Element aus niedrigen, eher dichten strauchigen
Pflanzen oder beschnittenen Bäumen, üblicherweise zur Abtrennung oder
Sichtschutz verwendet.

Was ist dann das?
http://de.wikipedia.org/wiki/Datei:H%C3%B6fen_hecke1.jpg

;)
durchaus üblich hier


Grüße aus der Eifel
Steffen

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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 05.02.2011 19:32, schrieb Frederik Ramm:

 Das Problem ist doch, dass da - egal wie viel ein Editor was zuklappt - 
 irgendwelche semantisch schwer verstaendlichen Zusatzinformationen an einem 
 Node haengen. Wieso hat diese Ampel hier Zusatztags, und die Ampel an der 
 naechsten Kreuzung hat keine? Was tue ich, wenn diese Ampel hier abgebaut 
 wird?

 André Reichelt wrote:

 Sollte ein Objekt mit versteckten Tags verändert oder gelöscht werden
 müsste der User über eine Warnmeldung darauf hingewiesen werden. Das ist
 aber, denke ich, obligatorisch.
 
 Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt hier ist 
 irgendwas, was Du nicht verstehst, und das, was Du hier gerade machen willst, 
 kann Folgen haben, die Du nicht verstehst und die wir hier leider auch nicht 
 erklaeren kann... - das ist *genau* der Kern des Problems.

Vielleicht läßt sich das technisch so einrichten, daß sich nicht der normale 
User mit Änderungen an den den Spezialtags auseinandersetzen muß, sondern die 
Leute, die sich damit auskennen.

Die Warnmeldung könnte dann aussagen: Lieber User, mit diesem Objekt hier ist 
irgendwas, was Du nicht verstehst, aber es macht nichts, wenn hier etwas 
kaputtgeht. Darum kümmern sich ggf. die Spezialisten.

Könnte man vielleicht irgendwelche Trigger einbauen, daß bei Löschungen oder 
wichtigen Änderungen von Objekten mit Tags aus dem TMC-Namensraum eine 
Benachrichtigung ausgelöst wird. Das könnte vielleicht eine Mail an eine 
TMC-Mailingliste sein oder eine Eintragung auf einer Wiki-Seite.
Dann müßten sich natürlich Leute finden, die diese Änderungsmeldungen prüfen 
und ggf. korrigieren. Was eine wichtige Änderung ist, müßte natürlich 
definiert werden. (Eine leichte Verschiebung einer Straße mit TMC-Tags gehört 
sicher nicht dazu.)
Ähnliches könnte man für Relationen machen.
Oder vielleicht gibt es externe Prüfmechanismen, mit denen man regelmäßig 
automatisch feststellen kann, ob die TMC-Tags noch konsistent sind.


Viele Grüße
Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1OY1AACgkQnMz9fgzDSqd1qQCfVAkrUH2GX9un5U1KDZN+knvw
tmAAn33mhwY9DszRQjTccosEVKDCNniD
=rix2
-END PGP SIGNATURE-

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

Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht

[Andreas Tille]

On Sat, Feb 05, 2011 at 10:00:38PM +0100, M∡rtin Koppenhoefer wrote:
 Am 5. Februar 2011 21:43 schrieb Andreas Tille andr...@an3as.eu:
  On Sat, Feb 05, 2011 at 03:47:56PM +0100, Michael Bemmerl wrote:
  Wenn das noch mal angefaßt werden würde: Kann mal jemand prüfen, ob das
  auch mit Mono gebaut werden kann.  Es soll Leute geben, die gar keinen
  Zugriff auf einen Windows-Rechner haben...
 
 
 das funktioniert bereits mit Mono, hatte das nicht auf einem
 Windowsrechner eingesetzt.

Ahhh, sehr schön.  Wo war noch mal die *Quelle* mit der nunmehr
gepatchten version?

Viele Grüße

 Andreas.

-- 
http://fam-tille.de

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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Bernd Wurst]

Hallo.

Am Sonntag 06 Februar 2011, 10:01:04 schrieb Bodo Meissner:
 Die Warnmeldung könnte dann aussagen: Lieber User, mit diesem Objekt hier
 ist irgendwas, was Du nicht verstehst, aber es macht nichts, wenn hier
 etwas kaputtgeht. Darum kümmern sich ggf. die Spezialisten.

Und was soll das dann dem Benutzer sagen? Soll er jetzt Änderungen machen oder 
nicht?

Das ist FUD erster Güte.

Gruß, Bernd

-- 
Die Frauen ändern zwar manchmal ihre Ansichten,
aber nie ihre Absichten.  -  Curt Goetz (dt. Schriftsteller)


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Weinlagen

[Falk Zscheile]

2011/2/5 Johannes Huesing johan...@huesing.name:
 Und nehme ich den Ortsnamen in die Lagebezeichnung auf? Schwarzlay und der
 Rest ergibt sich aus Grenzpolygonen oder Ürziger Schwarzlay?

Da bin ich mir auch noch unschlüssig, aber ich denke ein bisschen
Redundanz kann nicht schaden. Alles andere, insesondere op der
potentielle Ersteller einer openvinemap relationen oder Tags
bevorzugt, muss die Zukunft zeigen.

Für die Lage würde ich nach bisherigem Stand vineyard:locality= für
den Ort könnte man dann analog vineyard:village= verwenden.

Was mir noch völlig unklar ist, ob sich dieses Schema auch kompatibel
zur geografischen Herkunftsbezeichnung für französische Weine
(Appellation d’Origine Contrôlée) gestalten lässt.


Gruß, Falk

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

Re: [Talk-de] Weinlagen

[M∡rtin Koppenhoefer]

Am 6. Februar 2011 10:59 schrieb Falk Zscheile falk.zsche...@googlemail.com:
 Für die Lage würde ich nach bisherigem Stand vineyard:locality= für
 den Ort könnte man dann analog vineyard:village= verwenden.


vineyard:village=Stuttgart ;-)

Gruß Martin

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

Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume

[Falk Zscheile]

Am 5. Februar 2011 21:37 schrieb Steffen Heinz eifelhu...@gmx.de:
 Am 05.02.2011 18:55, schrieb Falk Zscheile:

 Wenn Du mit meinem Vorschlag Bauchschmerzen hast, dann bleibt Dir
 nichts anderes übrig, als Dir etwas eigenes auszudenken, wie z.B.
 landuse=monschauer_hecke. Die Definition hierfür wäre dann Hecke mit
 dazwischen hochgewachsenen Bäumen. Ich würde eine solche Lösung aber
 nicht gut finden. Ich bin ein Verfechter möglichst wenige Dinge und
 damit Definitionen in einem Tag zu verschmelzen.

  Was ist denn für OSM ein Hecke?
 im normalen Sprachgebaut fängt die bei wenigen cm an und hört bei haushoch
 auf.


 mal sind es aufgereihte gleiche Pflanzen die auch ab und an beschnitten
 werden,,  mal ist alles mögliche was in einer Reihe steht und Felder schützt
 (Knicks), auch ja, dann gibt es noch *Benjeshecken... so ist halt die
 Flurhecke auch ein Typ

Gene, es ist eine Hecke, aber nur ein bestimmter Typ aus einer
Vielzahl von Typen. Wenn Du das mitteilen willst, dann bietet sich ein
Sub-Tag an, beispielsweise hedge:type=. Nach diesem Schema kannst Du
dann auch Höhe und Breite der Hecke angeben, wenn Du das möchtest.


 kennzeichen der Hecken sind halt linienförmig, dicht stehend, schließlich
 auch absperrend. durchgehen ist nicht einfach im Gegensatz zu Baumreihen
 oder Alleen


Hier hast Du doch schon eine sehr brauchbare Definition geliefert. Das
Hecken unter dem Schlüssel barrier= gezogen wurden bestätigt deine
Auffassung :-)

Gruß, Falk

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

Re: [Talk-de] Weinlagen

[Falk Zscheile]

Am 6. Februar 2011 11:04 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:
 Am 6. Februar 2011 10:59 schrieb Falk Zscheile falk.zsche...@googlemail.com:
 Für die Lage würde ich nach bisherigem Stand vineyard:locality= für
 den Ort könnte man dann analog vineyard:village= verwenden.


 vineyard:village=Stuttgart ;-)

Wenn wir nach Bedeutung der Weine die in den Dörfern erzeugt werden
gehen ergibt sich eine ganz neue Landweinkarte. Ich denke Stuttgart
kann da ruhig village bleiben und an der Mosel werden einige Dörfer zu
town oder city ;-)

Gruß, Falk

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

Re: [Talk-de] Performanceprobleme bei Mapnik/SQL

[Frederik Ramm]

Hi,

Stephan Wolff wrote:
Ich hatte vermutet, dass meine verschachtelten Abfragen Schuld sind, 
aber Frederik hat mit dieser Beschreibung die Hauptursache getroffen.

Ich habe den Zeitbedarf verschiedener SQL-Abfragen für größere Bereiche
verglichen. Eine einfache Abfrage aller Punkte mit power=generator

$ time psql -c select count(*) from planet_point where power=generator 
and way  bounding_box ...


benötigte in meinem Testbereich etwa 2,5 Minuten.


Probier mal

CREATE INDEX generator_index ON planet_osm_point using GIST(way 
GIST_GEOMETRY_OPS) WHERE power=generator;


Der Request sollte nur wenige Minuten dauern. Danach muesste Deine 
Abfrage schneller sein.



Somit bleibt zur Beschleunigung nur die Möglichkeit, eine eigene
Datenbank vorab anzulegen. Kann man Osm2pgsql so konfigurieren,
dass eine weitere Tabelle mitgepflegt wird oder muss man in
regelmäßigen Abständen die gesamte Hauptdatenbank filtern?


Der Query oben macht im Effekt das; er erzeugt einen bedingten Index, in 
dem *nur* alle power=generator-Nodes anhand ihrer Position verzeichnet 
sind. Das braucht zusaetzlich Platz (aber nicht viel - sind ja nicht so 
viele Nodes) und verlangsamt Updates (aber nicht viel), sollte Abfragen 
aber deutlich beschleunigen.


Bye
Frederik

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

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

Re: [Talk-de] Weinlagen

[Henning Scholland]

Hallo
Evtl. könntet ihr das ganze mal an realen Beispielen durchgehen. Dann 
könnten auch nicht Weinexperten Tips geben, wie man das Schema aufbauen 
könnte.


Für mich als Laien wäre interessant:
Winzer: Weingut XY
Traube: Riesling
Lage: Rheinhessen

oder ist Lage noch etwas kleiner definiert? Dann
Lage ??

Der Namensraum vinery ist schonmal ganz gut.

Henning



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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Garry]

Am 06.02.2011 01:58, schrieb Frederik Ramm:

Hallo,

Garry wrote:
TMC benötigt Fixpunkte die auf einer Strasse liegen. Benötigt man 
einen riesen Aufwand um diese Fixpunkte mit externen Lösungen zu 
finden ist die ganze Sache Wertlos.


Ich bin nicht ueberzeugt, dass es sich hier um einen Riesenaufwand 
handelt. Ich koennte mir vorstellen, dass man mit einem halbwegs 
gescheiten Vorverarbeitungsschritt problemlos das Strassennetz aus OSM 
nehmen kann plus den TMC-Graphen und das gescheit aufeinander 
abbilden. Denn wie Du richtig sagst, werden die TMC-Segmente wohl kaum 
auf der Wiese liegen oder auf dem Radweg, der neben der Bundesstrasse 
verlaeuft. Und wer auch immer die OSM-Daten fuer das routingfaehige 
Navi aufbereitet, muss diese ganzen Daten doch eh durchnudeln.


Vergleich zu maxspeed: Hier könnte man auch alle verkehrsschildbedingte 
maxspeed-Tags durch mappen der entsprechenden Schilder
ersetzen. Diese Schilder kann man dann auch alle statt in OSM abzulegen 
in eine externe Datenbank auslagern.
OSM wäre etwas entrümpelt - und die Lust der 
(Freizeit)-Anwendungsprogrammierer maxspeed in eine Anwendung zu 
implementieren dahin...


Aber das ist jetzt von mir zugegebenermassen so dahingesagt, ich habe 
das noch nicht selber ausprobiert. Vielleicht schlummern da 
irgendwelche Hunde, die ich nicht kenne. Pascal weiss das sicher 
besser, deswegen versuche ich jetzt mal, bis zu seinem Talk auf der 
FOSSGIS nicht mehr weiterzuspekulieren ;)


Ein einziger User, der sich wegen TMC-Tags nicht traut, ein Objekt 
zu bearbeiten - und da gab es mindestens einen hier im Thread - 
reicht in meinen Augen schon zum Schadensbeweis. Denk dran, dass 
sich hier in der Liste nur die Top 1% herumtreiben, und frage 
Dich, wie viele andere erschrocken ihre Finger von einer 
Verbesserung gelassen haben.



Das ist absoluter Blödsinn!
Mit der Begründung müsstest Du als aller erstes die Relationen wieder 
abschaffen!


Sind wir uns also darin einig, dass jeder User, der durch 
was-auch-immmer erschrocken seine Finger von etwas laesst, einen 
Schaden darstellt? Egal ob TMC:c347:tabcdefghi:next_pointer=0x3728754 
oder durch eine Multipolygonrelation?

Klares jein, weil:
Das ist kein TMC-verursachtes Problem, das fing schon zur OSM-Urzeiten 
an als es darum ging einem Einsteiger zu erklären was unter 
highway=trunk oder highway=unclassified zu vestehen ist und auch heute 
noch gelegentlich zu Uneinigkeiten bei den Profis führt. Diese 
Einstiegshürde wurde entschärft in dem man in JOSM deutsche Begriffe 
(Landesstrasse,Kreisstrasse,..) eingesetzt hat - unter inkaufnahme der 
dadurch entstehenden Fehler weil es teilweise doch grössere 
Abweichungen  gibt.
Wenn man jetzt für TMC im Editor einfach nur sowas wie 
Verkehrsnachrichtendienst anzeigen lassen würde hätte man eine 
ähnliche Entschärfung.


Soll heissen es gibt ..zig Dingen die auch einem schon etwas 
geübteren User nicht geläufig sind und ihn davon abhalten können 
bestehende Daten aus seiner Sicht zu verbessern.


Genau, und diese Dinge muessen wir kennen, verstehen, im Griff 
behalten, bekaempfen, reduzieren.


Ich hab neulich, als ich eine Gruppe Studenten in OSM einfuehren 
sollte, schon ein Dorf in Turkmenistan mappen lassen, weil ich so viel 
gar nicht an einem Vormittag erklaeren konnte, wie die wissen 
muessten, um in einer deutschen Innenstadt was zu editieren.
Ohne diesen Studenten jetzt zu nahe treten zu wollen - einem Buschmann 
musst Du auch erstmal erklären was eine Ampel ist und was es mit den 
Farben auf sich hat, sonst tut er sich auch schwer in einer Stadt sicher 
zu bewegen...



Hast nicht gerade Du immer gross auf Deine Fahnen geschrieben dass 
wir nicht für eine bestimmte Anwendung taggen sollen?


Also wenn jemand 175000 Tags in Deutschland verteilt und wenn in der 
Mailingliste behauptet wird, dass deren Entfernung die 
Datennutzbarkeit in erheblichem Umfang einschraenken wuerde, dann 
wird doch mal die Frage erlaubt sein, worin konkret diese 
Datennutzbarkeit besteht?
Kommt aber mehr als Drohung wie Frage rüber: Wenn nicht gleich eine 
Erklärung kommt so dass ich das für gut befinde lösche ich die Daten.


Vielleicht verbessert es Dein Verständnis wenn Du noch ein paar weiter 
Bedingungen kennst die TMC geformt haben:
RDS,  das Radiodatensystem wurde in den 80er Jahren eingeführt um 
digitale Daten mit geringer Bandbreite zusammen mit dem normalen 
Musik/Sprachprogramm
eines UKW Senders(Kanal) wie z.B. SWR3 zu übertragen. Das RDS-System 
unterstütz dabei mehrere Datenkanäle wie z.B. (grob aus dem 
Gedächtniss)Uhrzeit, Sendernamen, Musikart, Programmname, aktueller 
Musiktitel... und eben auch TMC (TrafficMessageChanel).
TMC sollte es ermöglichen Verkehrsnachrichten ständig aktuell und 
unabhängig von den in der Regel halbstündlichen Verkehrsmeldungen per 
Radiosprecher zu
übertragen. Da die Bandbreite nur relativ wenige Bytes pro Minute(!) zu 
übertragen erlaubt mussten Verkehrsmeldungen möglichst kompakt 
übertragen werden was eben auch zu den 

Re: [Talk-de] Weinlagen

[Klaus Hartmann]

Am Sonntag, 6. Februar 2011, 11:36:23 schrieb Henning Scholland:
 oder ist Lage noch etwas kleiner definiert? Dann
 Lage ??
 
 Der Namensraum vinery ist schonmal ganz gut.
Nach dem deutschen Weingesetz gibt es 

- Anbaugebiete, das ist z.B. Rheinhessen, Nahe usw.
- Großlagen
- Einzellagen,

wobei jeder Weinberg normalerweise sowohl teil einer Groß- wie Einzellage ist.

Je nach Qualität wird entweder nur das Anbaugebiet, Anbaugebiet + Großlage 
oder Anbaugebiet + Einzellage am dem Etikett angegeben, wobei im letzten Fall 
die Angabe auch den Ortsnamen umfaßt.

MfG
Klaus

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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Henning Scholland]

Garry und Frederik Ramm schrieben eine Menge

Hallo
Eure Diskussion ist zwar schön und gut, doch sie führt irgendwie zu nichts.

So wie ich Frederik verstehe, geht es ihm darum, dass das ganze zu 
komplex ist und Mapper abschreckt, weil sie Angst ahben Fehler zu 
machen. Das kann ich durchaus verstehen. Das bedeutet aber nicht, dass 
man die Daten nicht in OSM abbilden sollte.


Die Editoren bräuchten eine Unterstützung für die Namensräume. Man 
müsste in den Objekteigenschaften sinnvolle Gliederungen einführen. Ein 
Beispiel wären aufklappende Tabellen. Was in anderen Programmen schon 
länger gemacht wird, wenn man solche tabellarischen Eigenschaften hat.
Der Mapper hat dann eine schnelle Übersicht, welche Eigenschaften des 
Objekt enthält. Bspw. Oberflächen, Buslinien und Verkehrsdaten. Die 
Eigenschaften können auch in Relationen abgelegt worden sein. Hier wäre 
eine einheitliche Darstellung aller Eigenschaften wünschenswert. Das die 
Buslinie in einer Relation getagt ist, ist dem Mapper an sich egal. 
Ähnliches gilt auch für Multipolygone. Auch hier ist nur interessant, 
dass die Fläche ein Wald ist. Wie das in den Daten hinterlegt ist, ist 
uninteressant.


Da keiner all diese Gruppen auswendig kennen kann, sollte es bspw. eine 
Übersicht in wiki-Form geben, wo kurz erklärt wird was es ist und worauf 
es ankommt: Absolute Lagegenauigkeit oder doch eher relative 
Lagegenauigkeit zu Objekt XY.


Das würde das Mappen einfacher und OSM flexiblerer machen.

Schönes Wochenende noch,
Henning


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

Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume

[Steffen Heinz]

Am 06.02.2011 11:07, schrieb Falk Zscheile:

  kennzeichen der Hecken sind halt linienförmig, dicht stehend, schließlich
  auch absperrend. durchgehen ist nicht einfach im Gegensatz zu Baumreihen
  oder Alleen


Hier hast Du doch schon eine sehr brauchbare Definition geliefert. Das
Hecken unter dem Schlüssel barrier= gezogen wurden bestätigt deine
Auffassung :-)


ich habe das mal hier für die Umgebung gemacht!
Ich bin mal hier im Hubschrauber geflogen (Ausstellung 10 minuten)
sah doll von oben aus über die ganze Landschaft Felder mit Grünzeugs drumrum



Grüße aus der Eifel
Steffen

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

[Talk-de] Die neue OSM-Wochennotiz Nr. 29

[Gehling Marc]

Die neue Wochennotiz Nr. 29 ist da, viel Spaß.

http://blog.openstreetmap.de/2011/02/osm-wochennotiz-nr-29/
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] osm2pgsql Import Probleme

[Alexander Matheisen]

 ich will mit osm2pgsql Daten in eine Postgis DB importieren. Leider
 werden aber nicht alle Objekte, die in der Quell-Datei vorhanden sind,
 auch importiert. Die Styledatei habe ich schon angepasst, hat aber
 leider nichts gebracht.


Hat keiner eine Idee? Ich bin echt aufgeschmissen...

Alex


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

Re: [Talk-de] osm2pgsql Import Probleme

[Stephan Knauss]

On 06.02.2011 13:48, Alexander Matheisen wrote:

ich will mit osm2pgsql Daten in eine Postgis DB importieren. Leider
werden aber nicht alle Objekte, die in der Quell-Datei vorhanden sind,
auch importiert. Die Styledatei habe ich schon angepasst, hat aber
leider nichts gebracht.


Willst du damit eine Karte rendern? osm2pgsql ist imho darauf optimiert.
Und eine API-DB zu bekommen solltest du dir mal osmosis mit den DB 
Schemas ansehen.


Ansonsten: Was fehlt denn genau? Deine Problembeschreibung ist etwas 
dürftig. Da muss man schon Hellseher sein um dein Problem erraten zu können.


Stephan


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

Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume

[Florian Lohoff]

On Sat, Feb 05, 2011 at 01:21:16PM +0100, RalfGesellensetter wrote:
 Hallo,
 
 gerade verfolge ich offenkundige Wasserläufe, die am Baumbestand gut
 zu erkennen sind: 52.0419731 N /  8.2430264 E
 
 Hier hat jemand landuse=forest getaggt, m.E. gehören die Bäume am
 Wasserlauf jedoch nicht mehr zum Wald bzw. sind als linienhafte Struktur
 (Baumreihe, Hecke) zu erfassen. Was sagen die Experten?

Ohne mir die Stelle jetzt exakt angesehen zu haben - Bei Wasserlaeufen 
die in einem Waldguertel liegen mache ich ein landuse=forest drauf.

Ab einer tiefe/breite von 5-6 Baeumen die man ja meistens hat ist
das fuer jemanden der daneben steht Blickdicht d.h. das ist erstmal
vom ansehen unklar wir gross das Gebuesch ist - Daher finde ich
Wald aka landuse=forest als merkmal richtig. Von aussen sieht
es aus wie ein Wald ...

Flo
-- 
Florian Lohoff f...@zz.de
 Professionell gesehen bin ich zu haben 


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

Re: [Talk-de] osm2pgsql Import Probleme

[Alexander Matheisen]

 Willst du damit eine Karte rendern? osm2pgsql ist imho darauf optimiert.
 Und eine API-DB zu bekommen solltest du dir mal osmosis mit den DB 
 Schemas ansehen.

Ich will für Flächen die Mittelpunkte abfragen können. Mit dem osmosis
Schema geht das wohl nicht.

 Ansonsten: Was fehlt denn genau? Deine Problembeschreibung ist etwas 
 dürftig. Da muss man schon Hellseher sein um dein Problem erraten zu können.

Ich habe mir mit osmosis aus einem File alle Objekte mit bestimmten Tags
herausgefiltert. Diese Datei habe ich nun mit osm2pgsl in die DB
importiert, leider sind manche Wege nicht vorhanden, weshalb ich in
meinem Script, was die Mittelpunkte abfragen soll, eine Fehlermeldung
bekomme. Am Script liegt es nicht, denn wenn ich das manuell abfragen
will, werde ich weder in points noch in polygon fündig, manche Wege sind
also einfach nicht da.


Alex


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

Re: [Talk-de] osm2pgsql Import Probleme

[M∡rtin Koppenhoefer]

Am 6. Februar 2011 14:25 schrieb Alexander Matheisen
alexandermathei...@ish.de:
 Ich habe mir mit osmosis aus einem File alle Objekte mit bestimmten Tags
 herausgefiltert. Diese Datei habe ich nun mit osm2pgsl in die DB
 importiert, leider sind manche Wege nicht vorhanden, weshalb ich in
 meinem Script, was die Mittelpunkte abfragen soll, eine Fehlermeldung
 bekomme. Am Script liegt es nicht, denn wenn ich das manuell abfragen
 will, werde ich weder in points noch in polygon fündig, manche Wege sind
 also einfach nicht da.

Ist das tag-abhaengig was da ist und was nicht? natural=coastline wird
z.B. von osm2pqsql automatisch rausgefiltert beim Import.

Gruss Martin

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

Re: [Talk-de] osm2pgsql Import Probleme

[Alexander Matheisen]

Am Sonntag, den 06.02.2011, 14:53 + schrieb M∡rtin Koppenhoefer:
 Am 6. Februar 2011 14:25 schrieb Alexander Matheisen
 alexandermathei...@ish.de:
  Ich habe mir mit osmosis aus einem File alle Objekte mit bestimmten Tags
  herausgefiltert. Diese Datei habe ich nun mit osm2pgsl in die DB
  importiert, leider sind manche Wege nicht vorhanden, weshalb ich in
  meinem Script, was die Mittelpunkte abfragen soll, eine Fehlermeldung
  bekomme. Am Script liegt es nicht, denn wenn ich das manuell abfragen
  will, werde ich weder in points noch in polygon fündig, manche Wege sind
  also einfach nicht da.
 
 Ist das tag-abhaengig was da ist und was nicht? natural=coastline wird
 z.B. von osm2pqsql automatisch rausgefiltert beim Import.

Das hatte ich auch vermutet und deshalb die style-Datei angepasst,
allerdings hat das nichts gebracht. Eigentlich sollte er nichts mehr
rausschmeißen, da ich nun alle interessanten Tags dort reingenommen
habe. Wie gesagt, eigentlich...


Alex



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

Re: [Talk-de] Weinlagen

[M∡rtin Koppenhoefer]

Am 6. Februar 2011 10:11 schrieb Falk Zscheile falk.zsche...@googlemail.com:
 Am 6. Februar 2011 11:04 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:
 Am 6. Februar 2011 10:59 schrieb Falk Zscheile 
 falk.zsche...@googlemail.com:
 Für die Lage würde ich nach bisherigem Stand vineyard:locality= für
 den Ort könnte man dann analog vineyard:village= verwenden.


 vineyard:village=Stuttgart ;-)

 Wenn wir nach Bedeutung der Weine die in den Dörfern erzeugt werden
 gehen ergibt sich eine ganz neue Landweinkarte. Ich denke Stuttgart
 kann da ruhig village bleiben und an der Mosel werden einige Dörfer zu
 town oder city ;-)


ich habe auch kein grosses Problem damit, Stuttgart als Dorf zu bezeichnen ;-)
Wuerde allerdings die Klassifikation, ob eine Lage oder ein
Anbaugebiet gut oder schlecht
sind eher in einer externen Datenbank haben wollen. Von daher ruhig
ein vineyard:region (oder auch village) fuer das Anbaugebiet, aber das
tag dann nicht variieren nach Qualitaet.

Gruss Martin

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

Re: [Talk-de] Weinlagen

[M∡rtin Koppenhoefer]

Am 6. Februar 2011 11:11 schrieb Klaus Hartmann koc.hartm...@t-online.de:
 Am Sonntag, 6. Februar 2011, 11:36:23 schrieb Henning Scholland:
 oder ist Lage noch etwas kleiner definiert? Dann
 Lage ??

 Der Namensraum vinery ist schonmal ganz gut.
 Nach dem deutschen Weingesetz gibt es

 - Anbaugebiete, das ist z.B. Rheinhessen, Nahe usw.
 - Großlagen
 - Einzellagen,

 wobei jeder Weinberg normalerweise sowohl teil einer Groß- wie Einzellage ist.


man sollte man bei den anderen Weinanbaulaendern nachfragen, wie das
dort geregelt ist, so dass man nach Moeglichkeit in international
verwendbares Schema erhaelt. Ich werde mal in Italien nachfragen,
fehlen noch mind. Spanien, Portugal, Frankreich, Ungarn, Rumaenien,
Bulgarien, Griechenland, Tuerkei, Chile, Suedafrika, Kalifornien und
Australien.

 Je nach Qualität wird entweder nur das Anbaugebiet, Anbaugebiet + Großlage
 oder Anbaugebiet + Einzellage am dem Etikett angegeben, wobei im letzten Fall
 die Angabe auch den Ortsnamen umfaßt.


ja, wobei wir ja nur die Gebiete bzw. Einzellagen taggen wollen, und
nicht die Weine ;-)


Gruss Martin

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

Re: [Talk-de] osm2pgsql Import Probleme

[Frederik Ramm]

Hallo,

Alexander Matheisen wrote:

Ich habe mir mit osmosis aus einem File alle Objekte mit bestimmten Tags
herausgefiltert. 


Und in diesem File sind die Ways also definitiv alle drin?


Diese Datei habe ich nun mit osm2pgsl in die DB
importiert, leider sind manche Wege nicht vorhanden, weshalb ich in
meinem Script, was die Mittelpunkte abfragen soll, eine Fehlermeldung
bekomme. Am Script liegt es nicht, denn wenn ich das manuell abfragen
will, werde ich weder in points noch in polygon fündig, manche Wege sind
also einfach nicht da.


Entweder bringst Du irgendwie was mit Way-/Relation-Ids durcheinander, 
oder Du hast eventuell irgendwelche Selbstueberschneidungen drin, so 
dass einzelne Geometrien beim Import zurueckgewiesen werden?


Bye
Frederik

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

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

Re: [Talk-de] osm2pgsql Import Probleme

[Alexander Matheisen]

 Alexander Matheisen wrote:
  Ich habe mir mit osmosis aus einem File alle Objekte mit bestimmten Tags
  herausgefiltert. 
 
 Und in diesem File sind die Ways also definitiv alle drin?

Ja, jedes benötigte Tag habe ich so eingetragen:
way   tag   text polygon

  Diese Datei habe ich nun mit osm2pgsl in die DB
  importiert, leider sind manche Wege nicht vorhanden, weshalb ich in
  meinem Script, was die Mittelpunkte abfragen soll, eine Fehlermeldung
  bekomme. Am Script liegt es nicht, denn wenn ich das manuell abfragen
  will, werde ich weder in points noch in polygon fündig, manche Wege sind
  also einfach nicht da.
 
 Entweder bringst Du irgendwie was mit Way-/Relation-Ids durcheinander, 
 oder Du hast eventuell irgendwelche Selbstueberschneidungen drin, so 
 dass einzelne Geometrien beim Import zurueckgewiesen werden?

Also es sollte definitiv funktionieren, bei den meisten tut es das ja
auch. Aber selbst mit einer Abfrage wie SELECT osm_id FROM
planet_polygon/line WHERE osm_id = x; funktionieren nicht.

Bei den Nodes hat es mit dem selben Stylefile übrigens ohne Probleme
funktioniert...


Alex


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

Re: [Talk-de] TMC-Reform (war Re: Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?))

[Sven Anders]

Am 05.02.2011 15:01, schrieb Wolfgang:

Hallo,
Am Samstag 05 Februar 2011 10:28:24 schrieb Ulf Lamping:

[ ]


(CID) is replaced by the country-id (e.f. 58 for Germany)

legt nahe, daß hier schlicht ein Tippfehler ist und es besser:

(CID) is replaced by the country-id (e.g. 58 for Germany)

heissen sollte (hab's korrigiert). Aus diesem Satz kann man schon gut
herauslesen, daß CID dann wohl eine Abkürzung für country-id sein dürfte
und 58 dabei der Wert ist, der Deutschland repräsentiert.


Die Beschreibung ist allerdings aus anderen Gründen unzureichend. Ich
kann herauslesen wie die Tags zustandekommen.

Damit kann ich aber weder meine eigene TMC Software schreiben (die
Abbildung der TMC Empfangsdaten auf die Tags bleibt unklar) - was
allerdings auch nicht unbedingt hier stehen muß.

Auch ist es keine gute Anleitung wie ein Mapper mit diesen Tags
umzugehen hat. Das Problem haben wir aber auch bei vielen anderen Tag
Beschreibungen.


[ ]


Man könnte sicher hier und da Sachen vereinfachen, aber so krass wie du
es darstellst ist es nun auch nicht ...

Gruß, ULFL

P.S: Das die Beschreibung etwas kryptisch ist, liegt sicher auch daran,
das bislang kaum einer danach gefragt hat. Ich kann mich zumindest nicht
dran erinnern, daß hier vorher schonmal solche Fragen wie deine gefragt
wurden.


nachdem dieser Thread aus dem ursprünglichen destruktiven Ansatz in ein
sachlicheres Fahrwasser gelangt ist, könnte man sich vielleicht überlegen, wie
man die tags so gestaltet, dass sie von Nicht-Insidern wie mir auch erahnt und
vor allem einigermaßen sicher gehandhabt werden.

Das Problem sehe ich weniger im Löschen oder Nicht-Verstehen der tags. Wenn da
tmc-Kram drin steht, lass ich die Node am Way dran, lösche, falls
erforderlich, eine andere und schiebe diese dann so, dass es geometrisch
passt. Mit Ampel- oder anderen tags beißt es sich auch nicht, das ist nicht
die eigentliche Baustelle.

Ein Problem bekommt der Normalmapper, wenn eine Straße, wie selbst in den
Großstädten noch häufig, nicht korrekt gemappt wurde. Problematisch ist häufig
die Zuordnung baulich getrennt - nicht baulich getrennt. Wenn das falsch
gemappt wurde, ist das verwirrend für den Benutzer, der die Karte mit der
Realität vergleicht.

Hier beginnt jetzt die Schwelle für den Mapper. Was soll er mit den ganzen
Sch-tags und -relationen machen, die tmc, Bus und weiß-der-Henker-was
betreffen? Ich habe mal in HH eine ziemlich zentrale Hauptstraße trennen
müssen. Man muss da schon etwas Mut zur Lücke haben und ansonsten einfach
raten und sich ein paar Stellen ansehen, wo die Fahrbahnen entsprechend
getrennt sind. Hier sollten wir ansetzen, nach dem Motto: Wenn etwas
funktionieren soll, frage jemanden, der sich damit auskennt, aber wenn du
etwas erklärt haben willst, frage jemanden, der sich damit nicht auskennt. Ein
Experte kann meistens nicht beschreiben, was ihm selbst klar ist.

Ich bin dafür,
1. die tags so weit wie möglich in eine verständlichere Schreibweise
umzusetzen. Das kann durch ein Script geschehen, wenn man sich auf eine
Schreibweise verständigt hat. Dabei geht die schon erbrachte Arbeit nicht
verloren.
2. im Wiki ein Kochrezept zu hinterlegen, mit dessen Hilfe der Mapper die
häufigsten Vorgänge wie Punkt verschieben, Fahrbahnen trennen, Fahrbahnen
zusammenfassen, Abbiegespur abtrennen etc. einfach bearbeiten kann.
3. für die Editoren ein plugin anzubieten, dass die Standardaufgaben dem
Mapper abnimmt.
4. das ganze nicht nur für tmc, sondern auch für Bus-Relationen und andere
nicht selbsterklärende Objekte.

Bespiel:
TMC:cid_58:tabcd_1:Class=Point

TMC = Namensraum, sinnvoll
cid_58 haben wir jetzt gelernt, ist Deutschland. Besser wäre möglicherweise
TMC:country=58;(germany)
tabcd_1 sagt mir gar nichts, ich habe auch nicht nachgesehen, will ich auch
nicht, ich will mappen. Wie wäre es mit TMC:whatever=1;(verständliches
Stichwort)?
Class sagt mir, dass hier irgendetwas klassifiziert wird, vermutlich, dass es
sich um einen Einzelpunkt handelt. Also:
TMC:Class=Point

Damit würde aus dem obigen
TMC:cid_58:tabcd_1:Class=Point

ein
TMC:country=58;(germany)
TMC:TableCommand=1;(very important) /* frei geraten */
TMC:Class=Point;(single waypoint)   /* auch frei geraten */


(ich erfinde mal etwas ich kenne die polnischen TMC Daten nicht (gibt es 
welche?) und bin zu faul die deutschen nachzusehen)


Nehmen wir den Grenzübergang Deutschland Polen:

TMC:cid_62:tabcd_1:LocationCode=27313

In Deutchland hat der selbe Grenzübergang (im Zweifel ein OSM Node) den 
Eintrag:


TMC:cid_58:tabcd_1:LocationCode=52323

Außerden könnte es sein, das sich 2012 die Hälfte aller Hersteller aller 
Navis zusammentun und ein eigenes TMC Schema mit tabcd 2 erfindet, weil 
sie  das Deutsche Bundesamt saftige Gebühren für die Nutzung unter einer 
unfreien Lizenz einführt.  Dann gebe es evtl. noch einen Enitrag:


TMC:cid_58:tabcd_2:LocationCode=99432

Wenn man sagt: Wer TMC benutzen möchte soll sich die Daten vom Bundesamt 
sowieso holen (und diese nicht aus OSM 

Re: [Talk-de] osm2pgsql Import Probleme

[Frederik Ramm]

Hi,

Alexander Matheisen wrote:

Ich habe mir mit osmosis aus einem File alle Objekte mit bestimmten Tags
herausgefiltert. 



Und in diesem File sind die Ways also definitiv alle drin?


Ja, jedes benötigte Tag habe ich so eingetragen:
way   tag   text polygon


Ich meine: In dem File, das Du mit osmosis erzeugt hast, sind da alle 
drin? Wenn Du


grep 'id=12345' meinedatei.osm

machst, findest Du alle fraglichen IDs? Und das OSM-File enthaelt auch 
alle Nodes, die von dem betr. Way referenziert wurden?


Bye
Frederik

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

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

Re: [Talk-de] osm2pgsql Import Probleme

[Alexander Matheisen]

 Ich meine: In dem File, das Du mit osmosis erzeugt hast, sind da alle 
 drin? Wenn Du

Da sind alle drin. Das Problem ist ja, dass die Wege zwar in der
einzuspielenden Datei sind, aber nicht in der DB.

 machst, findest Du alle fraglichen IDs? Und das OSM-File enthaelt auch 
 alle Nodes, die von dem betr. Way referenziert wurden?

Das habe ich noch nicht getestet, danke für den Hinweis, werde es gleich
mal prüfen.


Alex



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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Sven Anders]

Am 06.02.2011 10:01, schrieb Bodo Meissner:

Oder vielleicht gibt es externe Prüfmechanismen, mit denen man regelmäßig 
automatisch feststellen kann, ob die TMC-Tags noch konsistent sind.


Ja, genau das habe ich mit dem Aufbau des TMC Validators [1] bezweckt.
Er hat sicherlich viele Schwächen und zeigt z.Z. auch an manchen Stellen 
blödsinn an (weil ich mal wieder Basteln musste, arbeite aber schon an 
einer Korrektur).


Sicherlich fallen bei Pascals Auswertungen von OSM-TMC auch noch 
Validator daten an.


Allerdings brauchte man vermutlich noch eine Meta Datenbank dazu, um die 
ungereimtheiten im TMC zu dokumentieren.


(z.B. Straßen die zwar in TMC Daten noch existieren, in der realität 
aber nicht mehr).


Und das Tagging-Schema ist ja noch nicht einmal in sich konsistent (es 
gibt z.B. keine Einigkeit darüber wo der Knotenpunkt für eine 
Autobahn-Auffahrt am sinnvollsten gesetzt werden sollte.)


Frederik, ist es für dich okay, das wir mit einem Neuentwurf für ein TMC 
Schema bis nach der Fossgis warten? Oder sollen wir schon jetzt einen 
Neuentwurf anfangen?


Gruß
Sven

[1] http://osm-tmc.anders-hamburg.de/




Viele Grüße
Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1OY1AACgkQnMz9fgzDSqd1qQCfVAkrUH2GX9un5U1KDZN+knvw
tmAAn33mhwY9DszRQjTccosEVKDCNniD
=rix2
-END PGP SIGNATURE-

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



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

Re: [Talk-de] Liebe Deutsche

[Sven Anders]

Am 05.02.2011 21:33, schrieb Martien Scheepens:

Liebe Deutsche,

Wir mögen es, wenn ihr bei uns in den Urlaub fahrt, und wir mögen es auch,
wenn ihr in unserem Land als Mapper aktiv seid. Wir kommen nämlich auch zu
euch und mappen dort ;). Unser aktivster Mapper steht sogar bei euch in der
Top-5!
Wir korrigieren auch gerne eure Fehler, die ihr beim mappen macht. Seit 1578
sind wir allerdings von Deutschland (eher Deutschland) unabhängig und hat
sich unsere Sprache von eurer getrennt. Dementsprechend kann es vorkommen,
dass ihr andere Namen für bestimmte Orte habt als wir. Es sollte allerdings
nicht vorkommen, dass der deutsche Name als value des keys
*name*eingetragen wird. Wir mögen das nicht. Tobt euch stattdessen bei

*name:de* aus.



Hallo Martien,

als echter Deutscher (mit einem alten deutschen Perso), stimme ich dir 
100%ig zu. Aber sei dir bewußt, das 99,9% der deutschen OSMlern das 
nicht absichtlich machen.


Vermutlich ist es zielführender, wenn du diesen das direkt per 
OSM-Nachricht mitteilst.


 (Und sonst taufen wir auch einfach ein Paar Orte um :P)

Einen Edit-War zwischen deutschen und Niedeländern lehne ich schon 
aufgrund meine parzifischten Grundeinstellung ab. ;-)


Vielleicht sollten wir mal als Zeichen der Verbundenheit einen Ort in 
Deutschland für eine Woche  oder sowas in die niederländische Version 
unbennen?


Gruß
Sven

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

Re: [Talk-de] osm2pgsql Import Probleme

[Alexander Matheisen]

 Und das OSM-File enthaelt auch 
 alle Nodes, die von dem betr. Way referenziert wurden?

Da fehlen tatsächlich ein paar Nodes. Eigentlich sollten die aber drin
sein:

osmosis-0.38/bin/osmosis --rx cache.osm --nk keyList=$tags --tf
reject-ways --tf reject-relations --wx nodes.osm

osmosis-0.38/bin/osmosis --rx cache.osm --wk keyList=$tags --un --tf
reject-relations --wx ways.osm

osmosis-0.38/bin/osmosis --rx nodes.osm --rx ways.osm --m --wx
unsorted.osm

osmosis-0.38/bin/osmosis --rx unsorted.osm --s --wx data.osm


Das erste sollte nur Nodes mit den Tags rausfiltern, das zweite nur
Ways, wobei unused Nodes rausgefiltert werden. Es sollten also nicht
die Nodes, die in Ways enthalten sind, entfernt werden.
Hab ich da einen Denkfehler?


Alex


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

Re: [Talk-de] osm2pgsql Import Probleme

[Frederik Ramm]

Hallo,

Alexander Matheisen wrote:
Und das OSM-File enthaelt auch 
alle Nodes, die von dem betr. Way referenziert wurden?


Da fehlen tatsächlich ein paar Nodes. Eigentlich sollten die aber drin
sein:


Ist denn sichergestellt, dass sie in der Datei cache.osm ueberhaupt 
drin sind?


Bye
Frederik

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

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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Frederik Ramm]

Hallo,

Sven Anders wrote:
Frederik, ist es für dich okay, das wir mit einem Neuentwurf für ein TMC 
Schema bis nach der Fossgis warten? Oder sollen wir schon jetzt einen 
Neuentwurf anfangen?


fuer mich ok? Ich bin ja schon froh, wenn mir ueberhaupt jemand zuhoert ;)

Bye
Frederik

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

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

Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht

[Michael Bemmerl]

Andreas Tille schrieb:
 On Sat, Feb 05, 2011 at 10:00:38PM +0100, M∡rtin Koppenhoefer wrote:
 Am 5. Februar 2011 21:43 schrieb Andreas Tille andr...@an3as.eu:
 On Sat, Feb 05, 2011 at 03:47:56PM +0100, Michael Bemmerl wrote:
 Wenn das noch mal angefaßt werden würde: Kann mal jemand prüfen, ob das
 auch mit Mono gebaut werden kann.  Es soll Leute geben, die gar keinen
 Zugriff auf einen Windows-Rechner haben...

 das funktioniert bereits mit Mono, hatte das nicht auf einem
 Windowsrechner eingesetzt.
 
 Ahhh, sehr schön.  Wo war noch mal die *Quelle* mit der nunmehr
 gepatchten version?

Im SVN unter http://svn.openstreetmap.org/applications/utils/Srtm2Osm/trunk

Grüße,
Michi



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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Peter Wendorff]

Ganz kurzer Hinweis:
Die Idee mit der Unterstützung von Namensräumen im Editor habe ich vor 
drei Tagen hier geäußert (Betreff war Doppelpunkt).
Die Reaktionen waren eher mäßig und skeptisch bezüglich der generellen 
Umsetzbarkeit.


Da Du selbst dich da nicht beteiligt hast, hier das einfach noch als 
Hinweis; falls Du da Ideen beisteuern willst.


Kritisiert wurde das Konzept z.B. am Beispiel source:*, weil sich dabei 
unterschiedliche Source-Tags auf völlig unterschiedliche Attribute 
beziehen und nicht im üblichen Sinn eine Kategorie bilden.


Gruß
Peter

Am 06.02.2011 12:14, schrieb Henning Scholland:

Garry und Frederik Ramm schrieben eine Menge

Hallo
Eure Diskussion ist zwar schön und gut, doch sie führt irgendwie zu 
nichts.


So wie ich Frederik verstehe, geht es ihm darum, dass das ganze zu 
komplex ist und Mapper abschreckt, weil sie Angst ahben Fehler zu 
machen. Das kann ich durchaus verstehen. Das bedeutet aber nicht, dass 
man die Daten nicht in OSM abbilden sollte.


Die Editoren bräuchten eine Unterstützung für die Namensräume. Man 
müsste in den Objekteigenschaften sinnvolle Gliederungen einführen. 
Ein Beispiel wären aufklappende Tabellen. Was in anderen Programmen 
schon länger gemacht wird, wenn man solche tabellarischen 
Eigenschaften hat.
Der Mapper hat dann eine schnelle Übersicht, welche Eigenschaften des 
Objekt enthält. Bspw. Oberflächen, Buslinien und Verkehrsdaten. Die 
Eigenschaften können auch in Relationen abgelegt worden sein. Hier 
wäre eine einheitliche Darstellung aller Eigenschaften wünschenswert. 
Das die Buslinie in einer Relation getagt ist, ist dem Mapper an sich 
egal. Ähnliches gilt auch für Multipolygone. Auch hier ist nur 
interessant, dass die Fläche ein Wald ist. Wie das in den Daten 
hinterlegt ist, ist uninteressant.


Da keiner all diese Gruppen auswendig kennen kann, sollte es bspw. 
eine Übersicht in wiki-Form geben, wo kurz erklärt wird was es ist und 
worauf es ankommt: Absolute Lagegenauigkeit oder doch eher relative 
Lagegenauigkeit zu Objekt XY.


Das würde das Mappen einfacher und OSM flexiblerer machen.

Schönes Wochenende noch,
Henning


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



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

[Talk-de] OpenDEM - Freie Digitale Höhenmodelle und Höhendaten

[OpenDEM]

Hallo,

 

Mittels des OpenDEM Projektes soll eine Plattform entstehen um freie
Digitale Höhenmodelle und weitere freie Höhendaten (wie z.B. GPX tracks) zur
Verfügung zu stellen. 

 

Unter der URL http://www.opendem.info ist das Projekt ab sofort erreichbar
(nur in Englisch).

 

Viele Grüße,

 

Martin Over

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

Re: [Talk-de] Liebe Deutsche

[Johannes Huesing]

Sven Anders s...@anders-hamburg.de [Sun, Feb 06, 2011 at 05:42:53PM CET]:
[...]
 
 als echter Deutscher (mit einem alten deutschen Perso), stimme ich
 dir 100%ig zu. Aber sei dir bewußt, das 99,9% der deutschen OSMlern
 das nicht absichtlich machen.
 
 Vermutlich ist es zielführender, wenn du diesen das direkt per
 OSM-Nachricht mitteilst.
 

Vor allem haben geschätzte 99,9% der niederländischen Ortsnamen keine
gebräuchlichen deutschen Exonyme (mir fällt nur Arnheim, Nimwegen und
Herzogenbusch ein), daher kann ich mir nicht vorstellen, dass es sich
um ein Massenphänomen handelt. 
-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi)

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

Re: [Talk-de] osm2pgsql Import Probleme

[Walter Nordmann]

Alexander Matheisen wrote:
 
 Ich will für Flächen die Mittelpunkte abfragen können. Mit dem osmosis
 Schema geht das wohl nicht.
 
select astext(center(linestring))
 from ways where ...

gruss
walter

http://postgis.refractions.net/documentation/manual-1.5/reference.html



-
33,33% aller Statistiken beruhen auf kleinen Datenmengen.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/osm2pgsql-Import-Probleme-tp5995136p5998735.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)

[Stefan Keller]

Ok; du kannst ja nicht wissen, dass ich wohl mehr technische Elaborate
lese und schreibe als die meisten hier. Ich könnte auch ins Institut
fahren und ISO-Specs. lesen oder die Leute von Viasuisse selber
fragen, die ich nächstens treffe. Aber es geht ja nicht um mich, oder?

Ich habe mir gestern nochmals eine weitere Stunde(!) Zeit genommen und
ich muss nach wie vor feststellen: keine Chance, so etwas in einer
Viertelstunde zu verstehen. Wer's immer noch nicht glaubt, der soll
mir sagen wie man alleine aufgrund der OSM-Wiki-Seite und maximal
einer Liste von Weblinks dort (wenn es sie denn gäbe), herauslesen
kann wie man Tag TMC:cid_58:tabcd_1:LocationCode (mit Wert 52864)
interpretiert!
* Wo steht, dass CID ein Field ist? Was haben Fields in Tag-Namen
überhaupt zu suchen? Was ist die Country-ID z.B. für Norwegen?
* Warum braucht es tabcd_1? Woher weiss man, dass es nur die gibt
und man nicht mit tabcd_99 rechen muss?
* etc. ... der Tag und die von mir zitieren Sätze stehen dabei nur
exemplarisch da.

Ich bin mit dir einverstanden, dass es schön wäre, wenn man auch eine
Anleitung hätte, wie Mapper mit diesen Tags umzugehen haben oder wie
man damit eigene Software schreibt. Aber ich muss es nochmals sagen:
Zurzeit kann kaum einer das TMC-Tag-Schema verstehen, so wie es
aktuell beschrieben ist.

== Genau dies ist aber für mich eine klare Vorbedingung, um Daten in
OSM einzubetten, die grösserem Stil eingepflegt werden sollen. ==

Ein Tagging Schema muss u.a. verständlich, zugänglich und nach den
Regeln der Kunst verfasst sein. Unter verständlich verstehe ich,
dass das Wichtigste erläutert ist, um das Prinzip des Schemas zu
verstehen. Und unter zugänglich verstehe ich, ausgehend von einer
OSM-Wiki-Seite (also http://wiki.openstreetmap.org/wiki/Key:TMC, die
nicht wie aktuell zum Teil-Tag LocationCode weitergeleitet wird). Die
Regeln der Kunst sind in OSM etwas schwieriger zu definieren :-

Unterlagen zu TMC findet man nur spärlich: Kaum Event Lists und
Location Tables Das Wenige, das ich gefunden habe, waren Specs. zum
TMC-ExchangeFormat und zur ISO_14819-2:2003 sowie als Einstieg
http://www.tm.tfh-wildau.de/~sbruntha/wiki/index.php/RDS-TMC - obwohl
auch da das Konzeptionelle fehlt. Und wer sich mal wirklich die Zähne
ausbeissen will, dem seien einzigen TMC-Daten verraten, die ich nach
erwähnter Stunde im Web gefunden habe:
http://www.vegvesen.no/en/Professional/Technology/RDS+TMC . Für den
Link für deutsche Daten auf www.bast.de muss man sein Email preisgeben
und wohl warten... (da kommt ein Bestellformular).

Auf http://wiki.openstreetmap.org/wiki/Key:TMC sollte m.E. zuerst das
Konzept erläutert werden. Das beginnt mit einer Aussage, dass es sich
um ein topologisches Netz mit linearem Bezugssystem handelt und dass
man trennen soll zwischen TMC-Geometrien (um die es hier geht) und
RDS-TMC-Meldungen. Dann könnten die Tags erläutert werden - wenn sie
denn nach den Regeln der Kunst modelliert, bzw. codiert wären. Dann
Beispiele etc.

Hier erste Überlegungen am aktuellen Beispiel Tag
TMC:cid_58:tabcd_1:LocationCode=52864): Dieser Tag ist kein
selbstdokumentierender Name und der Doppelpunkt in Tags ist für Prefix
reserviert. Weitere Doppelpunkte in Tags verwirren Mensch und
Maschine.
= Daher könnte z.B. folgendes etwas sinniger sein:
tmc:locationcode=countryid_58:tablecode_1:52864.

Das ist jetzt erst ein erster Vorschlag und ich würde sehr gerne
weiter mithelfen, doch ist mir eine weitere Frage aufgefallen, die uns
wieder zur Relevanzdiskussion zurückführt:

= Wollen wir innerhalb in OSM wirklich eine weitere, überlagernde
Knoten-Kanten-Topologie - wie dies die TMC-Daten darstellen - pflegen,
je mit eigenen Tags (in TMC: TYPES) wie Water area;Urban
street;... und Untertags(??) (in TMC: SUBTYPES) wie Motorway;Ring
motorway;...?
= Entspricht TMC den Eignungskriterien
(http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS)?

Ich bin nun nach wie vor etwas unentschlossen. Sollen wir nun:
* So etwas schweren Herzens (und mit Begründung) ganz missbilligen?
* Nur ein Teil davon, d.h. die IDs in OSM verwalten - z.B. die
LocationCodes (Points) an Nodes?
* Oder alles dies in OSM gutheissen (denn zwei, drei melden sich
immer, die so etwas gut finden)?

LG, S.


Am 5. Februar 2011 10:28 schrieb Ulf Lamping ulf.lamp...@googlemail.com:
 Am 05.02.2011 02:22, schrieb Stefan Keller:

 Also so können wir den Relevanz-Thread nicht stehen lassen:
 Habe mal versucht mich ins Schema einzuarbeiten und muss jetzt sagen,
 dass dieses TMC ein Negativbeispiel ist - so wie die Tags daherkommen
 und wie sie (nicht) erklärt sind.

 Bereits beim erst besten Tag, z.B. TMC:LocationCode steht auf
 http://wiki.openstreetmap.org/wiki/Key:TMC:LocationCode
 Man betrachte mal dort den Satz (CID) is replaced by the country-id
 (e.f. 58 for Germany): Was ist e.f.? Was ist (CID)? Auf was bezieht
 sich das? (aha rechts steht da etwas kryptisches
 TMC:cid_(CID):tabcd_(TABCD):LocationCode). Dann wird die Erklärung
 von CID zwei Sätze weiter unten 

Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)

[Frederik Ramm]

Hi,

Stefan Keller wrote:

= Daher könnte z.B. folgendes etwas sinniger sein:
tmc:locationcode=countryid_58:tablecode_1:52864.


Ich denke, man koennte auch den Mut zur Luecke haben und einfach nur 
tmc_location_code=52864 schreiben oder so. Ok, man kriegt damit keine 
laenderuebergreifenden Meldungen abgebildet, aber kommen die so oft vor?


Ebenso mit dieser table (ulkigerweise dachte ich anfangs wegen tabcd 
immer, das waere ein Beispielwert, a-b-c-d...) - wenn es wirklich mal zu 
dem unwahrscheinlichen Fall kommt, dass wir zwei Tables parallel in 
OSM abbilden muessen, kann man das Problem *dann* loesen. (Es entspricht 
nicht der Tradition von OSM, ein komplexes Modell aufzubauen fuer Zeugs, 
das noch gar nicht gebraucht wird und bei dem unklar ist, ob es 
ueberhaupt jemals gebraucht wird - man macht erstmal was einfaches und 
kann das dann spaeter immer noch erweitern.)



Ich bin nun nach wie vor etwas unentschlossen. Sollen wir nun:
* So etwas schweren Herzens (und mit Begründung) ganz missbilligen?
* Nur ein Teil davon, d.h. die IDs in OSM verwalten - z.B. die
LocationCodes (Points) an Nodes?
* Oder alles dies in OSM gutheissen (denn zwei, drei melden sich
immer, die so etwas gut finden)?


Zwischen missbilligen und gutheissen gibt es ja auch noch 
tolerieren - so nach dem Motto, das ist zwar Murks, und eigentlich ist 
das auch jedem klar, aber wir haben grad nichts besseres.


Also ich koennte mir durchaus vorstellen, dass es gelingt, den groessten 
Teil des TMC-OSM-Matchings komplett extern zu machen, so dass man den 
gewuenschten Nutzen auch erzielen kann, ohne dass TMC-Tags in OSM sind. 
Wenn sich rausstellt, dass das weitgehend (aber nicht 100%) geht, dann 
koennte man sich ja eventuell darauf beschraenken, an den Stellen, wo es 
nicht automatisch geht, zu taggen. Und wenn es gar nicht geht, dann muss 
halt irgendwas in OSM drin bleiben - aber eine Nachbildung des externen 
Graphen in OSM halte ich, wie mehrfach gesagt, fuer falsch. Eventuell 
ist das gemacht worden, weil es so schwierig ist, an die Originaldaten 
heranzukommen (Du schriebst, man muesse erst ein Bestellformular 
ausfuellen?).


Bye
Frederik

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

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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Stefan Keller]

Hier nochmals mein letzter Senf dazu bis zur FOSSGIS :-:

* Namensräume ein/ausblenden im Editor wären wohl nützlich.
* Wanderwege und ÖPNV-Relationen widersprechen meines Wissens nicht
der Knoten-Kanten-Relationen-Tags-Struktur von OSM.
* Die aktuellen TMC-Tags missbrauchen den Prefix m.E.: tmc: is für
mich der Prefix; alles andere sind strukturierte Werte.
* Das aktuelle TMC-Schema überlagert OSM mit einer eigenen
(Sub-)Tag-Struktur und einer linearen Segmentierung (was das
OSM-Schema eindeutig verkomplizieren würde).
* Eine Relevanzdiskussion muss leider sein, auch wenn auch mich
Realtime und Verkehrsdaten faszinieren. Die Wiki-Seite
DE:Nutzung_von_OSM_durch_FIS könnte mind. ein Anfang für
Nicht-Eignungskriterien sein.

André wrote:
 Das wird sich aber auch nicht durch eine ID in eine externe Datenbank
 lösen lassen, da auch hier der User zunächst überprüfen muss, was das
 Tag bedeutet und wie er hier vorgehen muss. Also bringt uns auch die
 Geforderte ID in eine externe Datenbank keinen Schritt weiter.

Ich würde diesen Kompromiss nicht vorschnell verwerfen. Das
etabliert die Verknüpfung und signalisiert dem Mapper (und den
OSM-Tools), dass da was dranhängt.

LG, S.


Am 6. Februar 2011 20:26 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Ganz kurzer Hinweis:
 Die Idee mit der Unterstützung von Namensräumen im Editor habe ich vor
 drei Tagen hier geäußert (Betreff war Doppelpunkt).
 Die Reaktionen waren eher mäßig und skeptisch bezüglich der generellen
 Umsetzbarkeit.

 Da Du selbst dich da nicht beteiligt hast, hier das einfach noch als
 Hinweis; falls Du da Ideen beisteuern willst.

 Kritisiert wurde das Konzept z.B. am Beispiel source:*, weil sich dabei
 unterschiedliche Source-Tags auf völlig unterschiedliche Attribute beziehen
 und nicht im üblichen Sinn eine Kategorie bilden.

 Gruß
 Peter

 Am 06.02.2011 12:14, schrieb Henning Scholland:

 Garry und Frederik Ramm schrieben eine Menge

 Hallo
 Eure Diskussion ist zwar schön und gut, doch sie führt irgendwie zu
 nichts.

 So wie ich Frederik verstehe, geht es ihm darum, dass das ganze zu komplex
 ist und Mapper abschreckt, weil sie Angst ahben Fehler zu machen. Das kann
 ich durchaus verstehen. Das bedeutet aber nicht, dass man die Daten nicht in
 OSM abbilden sollte.

 Die Editoren bräuchten eine Unterstützung für die Namensräume. Man müsste
 in den Objekteigenschaften sinnvolle Gliederungen einführen. Ein Beispiel
 wären aufklappende Tabellen. Was in anderen Programmen schon länger gemacht
 wird, wenn man solche tabellarischen Eigenschaften hat.
 Der Mapper hat dann eine schnelle Übersicht, welche Eigenschaften des
 Objekt enthält. Bspw. Oberflächen, Buslinien und Verkehrsdaten. Die
 Eigenschaften können auch in Relationen abgelegt worden sein. Hier wäre eine
 einheitliche Darstellung aller Eigenschaften wünschenswert. Das die Buslinie
 in einer Relation getagt ist, ist dem Mapper an sich egal. Ähnliches gilt
 auch für Multipolygone. Auch hier ist nur interessant, dass die Fläche ein
 Wald ist. Wie das in den Daten hinterlegt ist, ist uninteressant.

 Da keiner all diese Gruppen auswendig kennen kann, sollte es bspw. eine
 Übersicht in wiki-Form geben, wo kurz erklärt wird was es ist und worauf es
 ankommt: Absolute Lagegenauigkeit oder doch eher relative Lagegenauigkeit zu
 Objekt XY.

 Das würde das Mappen einfacher und OSM flexiblerer machen.

 Schönes Wochenende noch,
 Henning


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


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


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

Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)

[Stefan Keller]

Betreffend Location Table und Event List schrieb Frederik :
 (Du schriebst, man muesse erst ein Bestellformular ausfuellen?)

Einzig wie gesagt Norwegen habe ich gefunden.
Für Deutschland:
http://www.bast.de/cln_007/nn_213316/DE/Aufgaben/abteilung-f/referat-f4/Location-Code-List/location-code-list-nutzungsbedingungen.html
In der Schweiz sind die Daten ziemlich sicher der Viasuisse
vorbehalten, wobei man schauen könnte, ob sich die D-AC-H-Daten nicht
hinter dem Tool der Schweizer Firma Geologix herausholen lassen:
http://www.geologix.ch/website.php?nav=,products,E,10 (ebenfalls auf
Bestellung :-),
Bei Österreich habe ich nichts mehr herausgefunden ausser wer
zuständig wäre:
http://de.wikipedia.org/wiki/Traffic_Message_Channel#.C3.96sterreich

LG, S.

Am 7. Februar 2011 01:21 schrieb Frederik Ramm frede...@remote.org:
 Hi,

 Stefan Keller wrote:

 = Daher könnte z.B. folgendes etwas sinniger sein:
 tmc:locationcode=countryid_58:tablecode_1:52864.

 Ich denke, man koennte auch den Mut zur Luecke haben und einfach nur
 tmc_location_code=52864 schreiben oder so. Ok, man kriegt damit keine
 laenderuebergreifenden Meldungen abgebildet, aber kommen die so oft vor?

 Ebenso mit dieser table (ulkigerweise dachte ich anfangs wegen tabcd
 immer, das waere ein Beispielwert, a-b-c-d...) - wenn es wirklich mal zu dem
 unwahrscheinlichen Fall kommt, dass wir zwei Tables parallel in OSM
 abbilden muessen, kann man das Problem *dann* loesen. (Es entspricht nicht
 der Tradition von OSM, ein komplexes Modell aufzubauen fuer Zeugs, das noch
 gar nicht gebraucht wird und bei dem unklar ist, ob es ueberhaupt jemals
 gebraucht wird - man macht erstmal was einfaches und kann das dann spaeter
 immer noch erweitern.)

 Ich bin nun nach wie vor etwas unentschlossen. Sollen wir nun:
 * So etwas schweren Herzens (und mit Begründung) ganz missbilligen?
 * Nur ein Teil davon, d.h. die IDs in OSM verwalten - z.B. die
 LocationCodes (Points) an Nodes?
 * Oder alles dies in OSM gutheissen (denn zwei, drei melden sich
 immer, die so etwas gut finden)?

 Zwischen missbilligen und gutheissen gibt es ja auch noch tolerieren -
 so nach dem Motto, das ist zwar Murks, und eigentlich ist das auch jedem
 klar, aber wir haben grad nichts besseres.

 Also ich koennte mir durchaus vorstellen, dass es gelingt, den groessten
 Teil des TMC-OSM-Matchings komplett extern zu machen, so dass man den
 gewuenschten Nutzen auch erzielen kann, ohne dass TMC-Tags in OSM sind. Wenn
 sich rausstellt, dass das weitgehend (aber nicht 100%) geht, dann koennte
 man sich ja eventuell darauf beschraenken, an den Stellen, wo es nicht
 automatisch geht, zu taggen. Und wenn es gar nicht geht, dann muss halt
 irgendwas in OSM drin bleiben - aber eine Nachbildung des externen Graphen
 in OSM halte ich, wie mehrfach gesagt, fuer falsch. Eventuell ist das
 gemacht worden, weil es so schwierig ist, an die Originaldaten heranzukommen
 (Du schriebst, man muesse erst ein Bestellformular ausfuellen?).

 Bye
 Frederik

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

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


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

Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)

[Ulf Lamping]

Am 07.02.2011 00:40, schrieb Stefan Keller:

Ich habe mir gestern nochmals eine weitere Stunde(!) Zeit genommen und
ich muss nach wie vor feststellen: keine Chance, so etwas in einer
Viertelstunde zu verstehen. Wer's immer noch nicht glaubt, der soll
mir sagen wie man alleine aufgrund der OSM-Wiki-Seite und maximal
einer Liste von Weblinks dort (wenn es sie denn gäbe), herauslesen
kann wie man Tag TMC:cid_58:tabcd_1:LocationCode (mit Wert 52864)
interpretiert!
* Wo steht, dass CID ein Field ist? Was haben Fields in Tag-Namen
überhaupt zu suchen? Was ist die Country-ID z.B. für Norwegen?
* Warum braucht es tabcd_1? Woher weiss man, dass es nur die gibt
und man nicht mit tabcd_99 rechen muss?
* etc. ... der Tag und die von mir zitieren Sätze stehen dabei nur
exemplarisch da.


http://wiki.openstreetmap.org/wiki/Key:TMC:LocationCode

* (CID) is replaced by the country-id (e.g. 58 for Germany)
* (TABCD) is replaced by the table-code (e.g. 1 for the only table 
of Germany).


Wenn ich also z.B. einen Node finde mit dem Tag:

TMC:cid_58:tabcd_1:LocationCode = 52864

Wird das wohl bedeuten: Dieser Node entspricht der ersten TMC Tabelle 
von Deutschland und hat dort den Wert 52864. Im Zweifel aber bitte die 
TMC Profis fragen.



Ich bin mit dir einverstanden, dass es schön wäre, wenn man auch eine
Anleitung hätte, wie Mapper mit diesen Tags umzugehen haben oder wie
man damit eigene Software schreibt. Aber ich muss es nochmals sagen:
Zurzeit kann kaum einer das TMC-Tag-Schema verstehen, so wie es
aktuell beschrieben ist.


Wenn man die Doku nicht verstehen will, dann hat man klar ein Problem 
damit. Nachfragen wäre vielleicht eine mögliche Lösung gewesen.



==  Genau dies ist aber für mich eine klare Vorbedingung, um Daten in
OSM einzubetten, die grösserem Stil eingepflegt werden sollen.==

Ein Tagging Schema muss u.a. verständlich, zugänglich und nach den
Regeln der Kunst verfasst sein.


Bitte nicht die Wörter muss und sollte verwechseln.

Prima, dann schmeissen wir die ÖPNV Daten demnächst alle wieder raus. 
DAS Schema ist nämlich auch kaum zu verstehen und das davon 2-3 
Varianten im Wiki stehen macht die Sachen noch schlimmer.



Unterlagen zu TMC findet man nur spärlich: Kaum Event Lists und
Location Tables Das Wenige, das ich gefunden habe, waren Specs. zum
TMC-ExchangeFormat und zur ISO_14819-2:2003 sowie als Einstieg
http://www.tm.tfh-wildau.de/~sbruntha/wiki/index.php/RDS-TMC - obwohl
auch da das Konzeptionelle fehlt. Und wer sich mal wirklich die Zähne
ausbeissen will, dem seien einzigen TMC-Daten verraten, die ich nach
erwähnter Stunde im Web gefunden habe:
http://www.vegvesen.no/en/Professional/Technology/RDS+TMC . Für den
Link für deutsche Daten auf www.bast.de muss man sein Email preisgeben
und wohl warten... (da kommt ein Bestellformular).


Das allgemein so wenig Literatur und fast keine Daten zum Thema TMC 
vorhanden ist, ist jetzt natürlich auch den Autoren der Wikiseiten 
anzulasten?!?



Auf http://wiki.openstreetmap.org/wiki/Key:TMC sollte m.E. zuerst das
Konzept erläutert werden. Das beginnt mit einer Aussage, dass es sich
um ein topologisches Netz mit linearem Bezugssystem handelt


... und hier wird mir klar, warum mir die Leute lieber sind, die sowas 
bei OSM einfach voran bringen und nicht wie hier anderen vorschreiben 
was diese tun sollten.


Das diese Leute dann lieber erstmal einen Versuch starten und nicht erst 
ein Buch über TMC schreiben wollen kann ich gut verstehen, so sind 
übrigens bei OSM sehr viele Dinge entstanden.


Gruß, ULFL

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

Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)

[Frederik Ramm]

Hallo,

Ulf Lamping wrote:
Prima, dann schmeissen wir die ÖPNV Daten demnächst alle wieder raus. 
DAS Schema ist nämlich auch kaum zu verstehen und das davon 2-3 
Varianten im Wiki stehen macht die Sachen noch schlimmer.


Das lese ich jetzt zum wiederholten Mal. Das ist aber kein Argument, 
oder genauer: Es ist tatsaechlich ein Argument, aber maximal eines fuer 
die Entfernung von OePNV-Daten und nicht eins fuer die Erhaltung von TMC.


Ausserdem liegt dem Argument die Annahme zugrunde, das es 
allgemeingueltige Kriterien gaebe, die einzelne Themen in ihrer Relevanz 
vergleichbar machen (wenn wir X erlauben, muessen wir auch Y erlauben, 
wenn wir A rauswerfen, muessen wir auch B rauswerfen). Ich moechte 
darauf hinweisen, dass ich weder behauptet noch gefordert habe, dass es 
solche Kritierien gibt - ich habe nur auf die m.E. bestehenden Nachteile 
beim TMC-Tagging hingewiesen, und andere haben das zu einer 
Relevanzdiskussion aufgebauscht, weil sie annahmen, dass man nicht 
ueber einen konkreten Fall diskutieren kann, ohne ein allgemeines 
Regelwerk im Hintergrund zu haben. Ich hingegen habe kein Problem damit.


Bye
Frederik

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

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

Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)

[Ulf Lamping]

Am 07.02.2011 01:21, schrieb Frederik Ramm:

Hi,

Stefan Keller wrote:

= Daher könnte z.B. folgendes etwas sinniger sein:
tmc:locationcode=countryid_58:tablecode_1:52864.


Ich denke, man koennte auch den Mut zur Luecke haben und einfach nur
tmc_location_code=52864 schreiben oder so. Ok, man kriegt damit keine
laenderuebergreifenden Meldungen abgebildet, aber kommen die so oft vor?


Frag mal die Leute in Trier, die können dir da ein Lied von singen ;-)


Ebenso mit dieser table (ulkigerweise dachte ich anfangs wegen tabcd
immer, das waere ein Beispielwert, a-b-c-d...) - wenn es wirklich mal zu
dem unwahrscheinlichen Fall kommt, dass wir zwei Tables parallel in
OSM abbilden muessen, kann man das Problem *dann* loesen. (Es entspricht
nicht der Tradition von OSM, ein komplexes Modell aufzubauen fuer Zeugs,
das noch gar nicht gebraucht wird und bei dem unklar ist, ob es
ueberhaupt jemals gebraucht wird - man macht erstmal was einfaches und
kann das dann spaeter immer noch erweitern.)


Ich glaube nicht das dies der wirklich kritische Punkt ist.


Also ich koennte mir durchaus vorstellen, dass es gelingt, den groessten
Teil des TMC-OSM-Matchings komplett extern zu machen, so dass man den
gewuenschten Nutzen auch erzielen kann, ohne dass TMC-Tags in OSM sind.


Über das Problem sinnvoll eine externe DB mit unserer zu verzahnen, also 
mit Minimum an manuellem Aufwand und benutzbar für Datenanwender, hatten 
wir doch schon häufiger gesprochen und bislang m.W. noch keine wirklich 
brauchbare Lösung gefunden.


Du kennst das Bild mit dem und hier geschieht ein Wunder Kasten kurz 
vor der Fertigstellung?


http://www.ethikpartei.ch/miracle1.jpg

Gruß, ULFL

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

Re: [Talk-de] Weinlagen

[M]

wie sollte man bei einem Weinberg den Namen der Lage angeben? Im
Weinbau ist es üblich damit anzugeben, von welchem Weinberg die
Trauben für den Wein stammen.


Was hat das denn mit anzugeben, also prahlen zu tun ??

Das man aus einer Lage mit den selben Trauben (eines Jahrgangs) einen 
guten Wein oder eine untrinkbare Blörre machen kann ist mir bewusst.



Gebe ich nur landuse=vineyard und name=Name_des_Weibergs an oder setze
ich dazu noch ein place=locality? Und dann gibt es ja noch
Großlagen, zu denen viele einzelne Weinberge gehören. Hier bietet
sich die Zusammenfassung über eine Relation an?


22. Lage: eine bestimmte Rebfläche (Einzellage) oder die Zusammenfassung 
solcher

Flächen (Großlage), aus deren Erträgen gleichwertige Weine gleichartiger
Geschmacksrichtungen hergestellt zu werden pflegen und die in einer 
Gemeinde oder

in mehreren Gemeinden desselben bestimmten Anbaugebietes belegen sind,

23. Bereich: eine Zusammenfassung mehrerer Lagen, aus deren Erträgen Weine
gleichartiger Geschmacksrichtung hergestellt zu werden pflegen und die 
in nahe
beieinander liegenden Gemeinden desselben bestimmten Anbaugebietes 
belegen sind,


Quelle: http://www.gesetze-im-internet.de/bundesrecht/weing_1994/gesamt.pdf

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

Re: [Talk-it] Convegno per dati ambientali della laguna di Venezia

[G Zamboni]

Il 06/02/2011 07:28, luca menini ha scritto:

Il 06 febbraio 2011 01:04, G Zambonigd.zamb...@tiscali.it  ha scritto:

Nella montagna di dati accessibili dal portale ce ne sono molto interessanti
per chi sta mappando la laguna (abbiamo appena cominciato a parlarne e
organizzarci), ma per ora mi sa che non possiamo farne proprio niente.
Eventualmente potremmo contattare i proprietari dei dati e provare a farceli
rilasciare.

Si, e' proprio questa la cosa da fare.
Comincierei proprio dal comune di Venezia.
Nelle pause del convegno, ho parlato con gli organizzatori e altri del
Comune di Venezia di OpenStreetMap.

Non sapevo che ci fosse qualche mapper. Peccato.
Tu che impressioni hai avuto? Che idee ti sei fatto? Quattro occhi 
vedono meglio di due e due teste ragionano meglio di una :-)



Nessuno di loro conosce OpenStreetMap.
Ma qualcuno del Comune è sicuramente a conoscenza in qualche modo di 
OSM. Gianluca aveva organizzato il mapping party con la partecipazione 
del Comune, anche se evidentemente era qualcun altro o di qualche altro 
ufficio.
Potremmo anche metterli in contatto, sperando che chi ha conosciuto 
OSM due mesi fa ne abbia avuto una buona impressione :-)



Abbiamo quindi ampio margine di miglioramento.

Credo sia alla nostra portata convincere il comune a rilasciare almeno
1 dataset, libero per ogni scopo entro il 2011.
Da quello che ho capito i dati più interessanti sono del Magistrato alle 
Acque (che tra l'altro ha competenza anche per la laguna di Grado) che 
dipende dal Ministero delle Infrastrutture, non dal Comune. Comunque 
l'idea è corretta.



Bisognerebbe pero' che il gruppo italiano di OSM si impegnasse poi a
rendere disponibile subito dopo questi dati su OSM.
Un impegno per subito mi pare forse un pò troppo. I cugini friulano 
hanno impiegato mesi ad importare i dati della regione avendo tra le 
fila smanettoni che erano in grado di gestire i dati, convertirli, ecc...
Qua in Veneto e attorno a Venezia abbiamo una comunità (me compreso) di 
autoapprendisti nella gestione di dati Gis, che mappa a tempo perso.
Non so se c'è qualcuno che si possa/voglia seriamente prendere un 
impegno per un'importazione in tempo breve.
Tra l'altro una volta che ricevo i dati devo valutarne il formato, la 
qualità, le informazioni che posso tenere e quelle eventualmente da 
eliminare, decidere se importare massivamente ( e non tutti digeriscono 
questo approccio ) o ricalcare ( che necessita di più tempo ).



Ci proviamo?

Sicuro. C'erano l'assessore all'ambiente, i tecnici del sistema 
informativo e l'Osservatorio della Laguna. Con chi hai parlato? Io 
comincerei con loro.

Sono stati loro a sollecitare commenti e richieste, giusto?

Ciao.
luca

Ciao
Giuliano

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

[Talk-it] vini / come sono organizzati in Italia?

[M∡rtin Koppenhoefer]

Nella lista tedesca e stato chiesto come si potrebbero taggare i vini
(zone di coltivazioni). Pare che la legge tedesca prevede la
differenziazione in
 - Anbaugebiete (Regione di coltivazione)
 - Großlagen (ubicazione generale)
 - Einzellagen (ubicazione particolare)

e gerarchica, quindi sempre incluso nel precedente.

le parole ho tradotto io e probabilmente non sono quelli esatti. La
domanda e come funziona in Italia (sicuramente ci sara una legge)?

ciao,
Martin

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

Re: [Talk-it] vini / come sono organizzati in Italia?

[Stefano Droghetti]

Il giorno dom, 06/02/2011 alle 15.11 +, M∡rtin Koppenhoefer ha
scritto: 
 Nella lista tedesca e stato chiesto come si potrebbero taggare i vini
 (zone di coltivazioni). Pare che la legge tedesca prevede la
 differenziazione in
  - Anbaugebiete (Regione di coltivazione)
  - Großlagen (ubicazione generale)
  - Einzellagen (ubicazione particolare)
 
 e gerarchica, quindi sempre incluso nel precedente.
 
 le parole ho tradotto io e probabilmente non sono quelli esatti. La
 domanda e come funziona in Italia (sicuramente ci sara una legge)?

Come al solito in Italia è un pelino più complicato... :D

http://www.vinostore.it/argomese/etichettaturavino.php


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

Re: [Talk-it] Openmtbmap down

[glaucos]

Megaupload e simili purtroppo non vanno bene:
One click hosters are also no option to me (inconvenient, not possible to
choose same name again, meaning updates painful to link, many people dislike
one click hosters, and simply not what I want). 
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Openmtbmap-down-tp5995015p5997953.html
Sent from the Italy mailing list archive at Nabble.com.

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

Re: [Talk-it] vini / come sono organizzati in Italia?

[M∡rtin Koppenhoefer]

2011/2/6 Stefano Droghetti stefano.droghe...@gmail.com:
 Il giorno dom, 06/02/2011 alle 15.11 +, M∡rtin Koppenhoefer ha
 scritto:
 Nella lista tedesca e stato chiesto come si potrebbero taggare i vini
 (zone di coltivazioni). Pare che la legge tedesca prevede la
 differenziazione in
  - Anbaugebiete (Regione di coltivazione)
  - Großlagen (ubicazione generale)
  - Einzellagen (ubicazione particolare)

 e gerarchica, quindi sempre incluso nel precedente.

 le parole ho tradotto io e probabilmente non sono quelli esatti. La
 domanda e come funziona in Italia (sicuramente ci sara una legge)?

 Come al solito in Italia è un pelino più complicato... :D

 http://www.vinostore.it/argomese/etichettaturavino.php


si, questo tratta sopratutto della classificazione del vino, in OSM
abbiamo solo bisogno di classificare i vigneti. Il testo è lungo,
scorrendo sopra ho trovato regione e zona di coltivazione con
sottotipo classico. Sapete se quest'ultimo è sinonimo con vitigno?

Poi c'è D.O.C. come sigla che porta anche conseguenze legali come
iscrizione all'alba:
Le DOC decadono se non vengono attivate entro tre anni dal loro
riconoscimento e quando per 5 anni consecutivi i produttori iscritti
all�albo dei vigneti non abbiano presentato denunce o, ancora, quando
la denominazione � stata utilizzata per meno del 15%, o quando, per 3
anni consecutivi, in pi� del 50% dei vigneti non sono rispettati i
disciplinari.

Quindi servirebbe un elenco ufficiale.

ho trovato una banca dati dell'Ministero delle politiche agricole
alimentari e forestali
http://www.politicheagricole.it/SettoriAgroalimentari/Vitivinicolo/Vino/vinidocdocgricerca
Fonte: MiPA - Direzione Generale Politiche Nazionali
putroppo Dati aggiornati al: febbraio 1999

poi il winegis
http://www.winegis.it/elenco_vini

con link a documenti ufficiali:
http://www.winegis.it/files/DECRETO%207%20novembre%202007.pdf

(i codici 190 pagine)

http://www.winegis.it/files/DECRETO%2028%20dicembre%202006.pdf

questo
http://www.winegis.it/files/DECRETO%2028%20dicembre%202006%20(all.4).pdf
dice, che ci sono 2 voci gerarchiche: la denominazione e eventualmente
una sottozona.

http://www.winegis.it/de/normative

quale contegono elenchi di regioni e zone, per essempio
ANNESSO
B. ELENCO CODICI VINI D.O. E I.G.T., in ordine alfabetico e per le
seguenti categorie :
Vini a Denominazione di Origine Controllate e Garantita D.O.C.G.
(Posizione 1 codici : A )
Vini a denominazione di Origine Controllata D.O.C (Posizione 1
codici : B )
Vini a Indicazione Geografica Tipica I.G.T. (Posizione 1 codici :
C )
=
Posizioni Codici
|1 - 4|5|6 - 8|9|10|11|12|13|14
=
ALBANA DI ROMAGNA
|A008 |X|004 |1|X |X |A |0 |X
ALBANA DI ROMAGNA AMABILE
|A008 |X|004 |1|X |X |A |0 |C
ALBANA DI ROMAGNA DOLCE
|A008 |X|004 |1|X |X |A |0 |D



lo potremmo copiare nel wiki, forse interessa qualcuno (dato che è
tanto forse basta il link).

Secondovoi, quanti livelli ci sono bisogno per fare uno sistema di
tagging che unisce D.O.C.G., D.O.C. e  I.G.T. ? Oppure sono dei
concetti diversi e bisogna per forza tenergli separati?

ciao,
Martin

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

[Talk-co] Cobertura bing: poblaciones de Bolívar, Sucre, Córdoba

[hyan...@gmail.com]

http://www.openstreetmap.org/?way=98473480
___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co

[Talk-co] Cobertura #bing Barrancabermeja

[ouɐɯnH]

http://www.openstreetmap.org/?way=98490132

-- 
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls,
.xlsx, .ppt, .pptx, .mdb, mdbx
OpenOffice es libre: se puede copiar, modificar y redistribuir
libremente. Gratis y totalmente legal.
http://GaleNUx.com es el sistema de información para la salud
--///--
Teléfono USA:  (347) 688-4473 (Google voice)
skype: llamarafredyrivera

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

[Talk-co] Cobertura #BING #pasto #galeras #nariño #volcano

[ouɐɯnH]

hola

Esta zona es importante mapearla, porque son frecuentes las
emergencias por el Volcán Galeras

http://www.openstreetmap.org/?way=98491074

-- 
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls,
.xlsx, .ppt, .pptx, .mdb, mdbx
OpenOffice es libre: se puede copiar, modificar y redistribuir
libremente. Gratis y totalmente legal.
http://GaleNUx.com es el sistema de información para la salud
--///--
Teléfono USA:  (347) 688-4473 (Google voice)
skype: llamarafredyrivera

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

[Talk-co] Colombia Department Boundary uploading completed

[dies38061]

(follow-up to message at 
http://lists.openstreetmap.org/pipermail/talk-co/2011-January/001843.html )

Loading of the OCHA-SIGOT boundary information for Departments is 100% done. 
--ceyockey

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

Re: [Talk-co] Colombia Department Boundary uploading completed

[Mike Dupont]

Sounds good,
once we have the municipalities loaded, then we need to remove the common
edges as well.
mike

On Sun, Feb 6, 2011 at 7:27 PM, dies38...@mypacks.net wrote:

 (follow-up to message at
 http://lists.openstreetmap.org/pipermail/talk-co/2011-January/001843.html)

 Loading of the OCHA-SIGOT boundary information for Departments is 100%
 done. --ceyockey

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




-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova and Albania flossk.org
flossal.org
___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co

[Talk-co] Cobertura bing Bolivar - Sucre - Magdalena

[hyan...@gmail.com]

http://www.openstreetmap.org/?way=98512940
___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co

[Talk-co] Removal of common edges for admin boundaries in Colombia

[dies38061]

Mike -- Would it be possible for you to run your algorithm on the current Departmental boundaries? I have removed most of the boundary redundancy, but I've not removed (much) node redundancy or "_ID" values for nodes. --ceyockey-Original Message-
From: Mike Dupont 
Sent: Feb 6, 2011 2:25 PM
To: OpenStreetMap Colombia 
Subject: Re: [Talk-co] Colombia Department Boundary uploading completed

Sounds good,once we have the municipalities loaded, then we need to remove the common edges as well.mikeOn Sun, Feb 6, 2011 at 7:27 PM,  dies38...@mypacks.net wrote:

(follow-up to message at http://lists.openstreetmap.org/pipermail/talk-co/2011-January/001843.html )



Loading of the OCHA-SIGOT boundary information for Departments is 100% done. --ceyockey

___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co
-- James Michael DuPontMember of Free Libre Open Source Software Kosova and Albania flossk.org flossal.org




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

[Talk-co] Department and Municipality uploads

[dies38061]

I have a feeling that the entire effort for Department and Municipality uploads 
should be moved out of the 2010 Floods section of the wiki and moved into the 
WikiProject Colombia section.  The reason I say this is that the administrative 
boundary establishment, though quite important for crisis response, is not 
directly related to that response and should be owned by the WikiProject 
rather than HOT.  --ceyockey


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

[Talk-lt] Tiltai

[Tomas Straupis]

Sveiki

  Kaip darome su dvigubais keliais/tiltais? Pagal nerašytą OSM
susitarimą, kad keliai/tiltai atskiriami į atskirus kelius tik tada,
jei tarp jų yra koks nors fizinis atskyrimas? Pvz. tvora, žolė.

  Dabar su nauju žymėtoju kalbėjau dėl Žirmūnų tilto susidvejinimo,
tai jis teisingai pasakė, kad tokius sudvejintus matė ir kitur. Ir
tikrai, yra ir daugiau tokių dvigubų...

-- 
Tomas Straupis

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

Re: [Talk-lt] Tiltai

[ieskok]

Labas,
mano nuomonė sutampa su OSM nuomone, kad nereikia skaidyti kelių(ir visų
išvestinių tipų) ten, kur jie nėra fiziškai atskirti.
Kiek pastebėjau, pas mus Lietuvoje, keliai skaidomi dėl dviejų priežasčių:
 - tai gražiau atrodo;
 - taip daro kiti.

Dėl pirmos priežasties yra aiškiai aprašyta čia -
http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer
ir
http://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer

Antra priežastis būdinga naujokams, kurie nenori pasigilinti į žymėjimo
ypatumus ir skubiai imasi ką nors keisti. Tokioje situacijoje belieka tik
paprašyti, kad naujokai pirma pasiskaitytų wiki ir tik poto imtųsi ką nors
keisti. Siūlau pradėti nuo čia -
http://wiki.openstreetmap.org/wiki/Beginners%27_guide

P.S. geriausi OSM žymėjimo pavyzdžiai - http://bestofosm.org/

 Sveiki

   Kaip darome su dvigubais keliais/tiltais? Pagal nerašytą OSM
 susitarimą, kad keliai/tiltai atskiriami į atskirus kelius tik tada,
 jei tarp jų yra koks nors fizinis atskyrimas? Pvz. tvora, žolė.

   Dabar su nauju žymėtoju kalbėjau dėl Žirmūnų tilto susidvejinimo,
 tai jis teisingai pasakė, kad tokius sudvejintus matė ir kitur. Ir
 tikrai, yra ir daugiau tokių dvigubų...

 --
 Tomas Straupis

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




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

Re: [Talk-es] Autovía de la Sagra CM-41 y CM-43

[jynus]

El 05/02/2011 20:55, Javier Martin lordhab...@gmail.com escribió:

 El 05/02/2011 20:48, sergio sevillano escribió:

 les has preguntado si dan permiso
 para usarlo en osm (licencia bysa y odbl) ??

 ¿Dices las fotos del PNOA? Porque para los planos no pensaba que hubiera
que hacer nada en particular, al fin y al cabo son documentos oficiales de
una Administración que fueron expuestos a información pública (aunque estén
hosteados en otro sitio)... Vamos, que a lo mejor me equivoco, pero pensaba
que tendrían la misma consideración que, por ejemplo, una sentencia judicial
(es decir, públicos y perfectamente reproducibles).

Ya veo que nadie lee mis correos :-):

http://lists.openstreetmap.org/pipermail/talk-es/2011-January/006931.html

El pensaba no es suficiente para OSM. Es necesario estar seguros. El estar
públicos y disponibles es distinto de estar bajo dominio público.

Como se consultó hace un tiempo en esta lista, los mapas de proyectos de
obras no suelen caer en la categoría de obras no protegidas.

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

Re: [Talk-es] Continuidad de elementos

[Oscar Orbe]

Hola.si se trata de ways que indican vías o zonas de tránsito de cualquier tipo 
(carreteras, caminos, escaleras para peatones, puentes , plazas... ) y 
efectivamente están pensados para pasar de uno a otro, yo creo que es mejor 
conectarlos. creo q eso es lo topologicamente correcto y ayuda a las 
aplicaciones que quieran calcular rutas (paseos a pie, en coche...)
--oscar
--- On Sat, 2/5/11, sergio sevillano sergiosevillano.m...@gmail.com wrote:

From: sergio sevillano sergiosevillano.m...@gmail.com
Subject: Re: [Talk-es] Continuidad de elementos
To: Discusión en Español de OpenStreetMap talk-es@openstreetmap.org
Date: Saturday, February 5, 2011, 9:34 PM

es difícil con ascii, igual un link a una situación real?

El 05/02/2011, a las 18:49, bv2mu...@uco.es escribió:

 Os pongo el siguiente ejemplo:
 
 || ---
       |             |
       |             |
       |             |
       ---
 --
 --
 
 unas escaleras junto a una plaza y una calle normal (residential)
 
 Me surge la siguiente duda: ¿es necesario que las escaleras y/o las calle 
 estén en contacto con la plaza?
 
 ___
 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



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

Re: [Talk-es] Autovía de la Sagra CM-41 y CM-43

[Javier Martin]

El 06/02/2011 11:35, jynus escribió:



El 05/02/2011 20:55, Javier Martin lordhab...@gmail.com 
mailto:lordhab...@gmail.com escribió:


 El 05/02/2011 20:48, sergio sevillano escribió:

 les has preguntado si dan permiso
 para usarlo en osm (licencia bysa y odbl) ??

 ¿Dices las fotos del PNOA? Porque para los planos no pensaba que 
hubiera que hacer nada en particular, al fin y al cabo son documentos 
oficiales de una Administración que fueron expuestos a información 
pública (aunque estén hosteados en otro sitio)... Vamos, que a lo 
mejor me equivoco, pero pensaba que tendrían la misma consideración 
que, por ejemplo, una sentencia judicial (es decir, públicos y 
perfectamente reproducibles).


Ya veo que nadie lee mis correos :-):

http://lists.openstreetmap.org/pipermail/talk-es/2011-January/006931.html

El pensaba no es suficiente para OSM. Es necesario estar seguros. El 
estar públicos y disponibles es distinto de estar bajo dominio público.


Como se consultó hace un tiempo en esta lista, los mapas de proyectos 
de obras no suelen caer en la categoría de obras no protegidas.




Bueno, suponiendo que tengas razón y que por tanto esos datos estén en 
situación dudosa, he sido extremadamente escrupuloso en poner en todos 
y cada uno de los datos que tienen como fuente esos planos las adecuadas 
etiquetas source y source:url, asi que si la consejería responsable en 
la JCCM interpusiera alguna queja o demanda y no se pudiera llegar a un 
acuerdo con ellos para que los cedan con licencia compatible con OSM, se 
pueden eliminar de forma fácil y sencilla. Pero dudo mucho que un 
Gobierno hiciera algo así, sobre todo con leyes y un clima que cada vez 
más les piden ser más abiertos con la información.
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Autovía de la Sagra CM-41 y CM-43

[Manuel García]

El 06/02/2011 20:01, Javier Martin escribió:
 Bueno, suponiendo que tengas razón y que por tanto esos datos estén en
 situación dudosa, he sido extremadamente escrupuloso en poner en todos
 y cada uno de los datos que tienen como fuente esos planos las adecuadas
 etiquetas source y source:url, asi que si la consejería responsable en
 la JCCM interpusiera alguna queja o demanda y no se pudiera llegar a un
 acuerdo con ellos para que los cedan con licencia compatible con OSM, se
 pueden eliminar de forma fácil y sencilla. Pero dudo mucho que un
 Gobierno hiciera algo así, sobre todo con leyes y un clima que cada vez
 más les piden ser más abiertos con la información.

No voy a redundar más en los motivos de por qué se debe pedir permiso (o
saber que se puede) antes de introducir cualquier dato en la base de
datos, ya que lo resume bien el mensaje de jynus.

Sólo quiero incidir en que el respeto a las licencias de los demás es
fundamental si quieres que respeten la licencia de lo que tú haces.

Y tampoco creo que importar datos y esperar que se queje alguien para
retirarlos sea la línea a seguir.

Saludos, Manuel.

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

Re: [Talk-es] Muchos huecos arreglados

[Oscar Orbe]

ok, tienes razón, los ID son FR-XXX, así que parece que efectivamente esos 15 
mil km2 son de licencia francesa
--oscar

--- On Sat, 2/5/11, andrzej zaborowski balr...@gmail.com wrote:

From: andrzej zaborowski balr...@gmail.com
Subject: Re: [Talk-es] Muchos huecos arreglados
To: Discusión en Español de OpenStreetMap talk-es@openstreetmap.org
Date: Saturday, February 5, 2011, 3:45 PM

2011/2/5 Oscar Orbe oskaro...@yahoo.com

 hola, yo creo que no fue así,yo creo que paso esto:

 los datos que han importado los franceses no son los datos que ha generado el 
 ministerio frances. los datos corine se generan conjuntamente con imagenes de 
 avion o satelite de toda europa occidental y no se distinguen fronteras 
 interiores en el momento de crear los poligonos. despues, en 2009, francia 
 cambio la licencia para los datos de francia, y extrajeron una parte del 
 total incluyendo el buffer de 10km, pero eso no significa que los datos del 
 buffer esten bajo la licencia francesa.

Me exprese mal, en vez de autor debia decir dueños de los derechos
de autor.  Puedes ver quien es por el tag source=, tambien figuran en
los reportes en eea.europa.eu.  No se que funcion exacta tuvieron las
instituciones locales de cada pais pero la version seamless
(fundida en las fronteras) se creo despues y esa es la obra de la
AEMA.
Lo de sabemos como son los franceses suena a una sobregeneralizacion.

Saludos

___
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] Continuidad de elementos

[bv2musae]

Oscar Orbe oskaro...@yahoo.com escribió:

Hola.si se trata de ways que indican vías o zonas de tránsito de  
cualquier tipo (carreteras, caminos, escaleras para peatones,  
puentes , plazas... ) y efectivamente están pensados para pasar de  
uno a otro, yo creo que es mejor conectarlos. creo q eso es lo  
topologicamente correcto y ayuda a las aplicaciones que quieran  
calcular rutas (paseos a pie, en coche...)

--oscar


Eso es en lo mismo que pensé yo. Suponía que si posteriormente se  
quieren realizar aplicaciones que calculen la mejor ruta (en coche,  
bici, a pie,...), sería necesario que estuviesen los elementos  
conectados. Pero entonces me surgía la duda de cómo conectar unas  
escaleras con una plaza y una calle normal (residential)...




--- On Sat, 2/5/11, sergio sevillano sergiosevillano.m...@gmail.com wrote:

From: sergio sevillano sergiosevillano.m...@gmail.com
Subject: Re: [Talk-es] Continuidad de elementos
To: Discusión en Español de OpenStreetMap talk-es@openstreetmap.org
Date: Saturday, February 5, 2011, 9:34 PM

es difícil con ascii, igual un link a una situación real?




Bueno, eso me pasa por querer meterme donde no me llaman... El ASCII  
no es lo mío. Pego a continuación un enlace a una zona que puede  
aclarar:


http://www.openstreetmap.org/?lat=37.166923lon=-4.148277zoom=18layers=M

¿la escalera se uniría por un nodo (el de la esquina) a la plaza?  
¿cómo uniría la plaza a la vía residential?


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

Re: [Talk-es] Modificación dato Corine

[bv2musae]

Oscar Orbe oskaro...@yahoo.com escribió:

hola,vaya pregunta!por supuesto q puedes y debes modificar cualquier  
poligono de corine q sea mejorable.
piensa q lo los datos de corine tienes inexctatitudes (a pesar d lo  
cual son un avance respecto al vacio)
ademas los bosuqes y olivares no son inmutables ni eternos, los  
bosques de españa crecen a un ritmo relativamente rapido
lo q yo haria es: si el poligono que vas a modificar es grande y  
solo puedes mejorar una parte de el, entonces partelo en dos trozos:  
uno q conoces bien y otro q no quieras modificar, a continuacion  
borra el trozo que conoces  bien y  rehazlo sin ponerle  
source=CORINE...
si el poligono que quieres modificar es pequeño puedes directamente  
borrarlo y rehacerlo sin ponerle la etiqueta de corine.
en general los datos de corine no tienen buena fama, es decir un  
poligono que diga source=CORINE... es normalmente peor que uno que  
no tenga ese tag, asi que en los que rehagas es mejor q no pongas el  
tag de corine para que se sepa q ese poligono esta hecho a mano y  
con mas cuidado que los de corine

--oscar




Hombre, uno quería ser prudente...  :-)  De todas formas, ya modifiqué  
levemente el contorno de uno de los polígono Corine. Lo que haré será  
seguir las instrucciones de Óscar y cortar el polígono, eliminando la  
etiqueta source: Corine en el que haga yo.


Gracias, Óscar.



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

[OSM-Talk-ZA] SA Power Grid Rendering

[Grant Slater]

Hi,

Myself along with some others have been adding the power grid network.
Bing imagery is high enough resolution in many areas to see the
pylons.

http://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/South_Africa

Regards
 Grant

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

Re: [OSM-talk-fr] Un cadastre un peu vide.

[Art Penteur]

Le 5 février 2011 23:04, Nicolas FRERY nico...@zoubi.info a écrit :

 j'ai voulu m'occuper d'un village, mais il manque tout un quartier sur le
 cadastre vectoriel. J'ai cru halusciner, alors j'ai foncé sur le site du
 cadastre, mais c'est bien vide :O


J'ai rencontré la même chose dans le tram à Labastide-Rouairoux ou
Saint-amans-valtoré.

Art.

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