[talk-ph] Amenity areas now have icons in Mapnik
Hi guys, Amenities mapped as either nodes or areas now have icons rendered in the Mapnik layer. Before, only amenity nodes have icons (though areas already have icons in the Osmarender layer). This means that there may be redundant data in the database. For example, this Shell station now has redundant labels because the area and a node are both tagged as amenity=fuel and name=Shell: http://osm.org/go/4zhA0KFii--?layers=B000FTFTT Happy cleaning-up, guys! (As soon as the OSM API goes back up this Monday.) :-) Eugene / seav -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] Mysterious PostGIS Problem with Polygons
--- On Sat, 22/8/09, Jon Burgess jburgess...@googlemail.com wrote:
In part it could be caused by invalid geometries. Postgis
reports that
only Polska is actually a valid polygon geometry. Any
errors could upset
algorithms like ST_Within().
gis= select name,isvalid(way) from planet_osm_polygon
where
boundary='administrative' AND admin_level='2' AND name in
('Deutschland','Danmark','Polska','Nederland','Australia','Italia');
NOTICE: Hole lies outside shell
name | isvalid
-+-
Australia | f
Is Australia listed as false because the polygon used doesn't just cover
Australia but 4 or so external territories? These are islands in the Pacific
and Indian Oceans.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
I'm with Martin on this one - up/down is better than nothing and is useful in its own right on steps for example. Mike Harris -Original Message- From: Morten Kjeldgaard [mailto:m...@bioxray.au.dk] Sent: 21 August 2009 17:11 To: m...@koppenhoefer.com Cc: talk Subject: Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down On 21/08/2009, at 03.00, Martin Koppenhoefer wrote: Yeah, numeric value is better, but up/down is better than nothing. I think both should be allowed and within the scope of the proposal. if you already have good elevation data you can also tag the nodes with ele=xy (but nodes can always be moved, so this data might not be most reliable). Inclines are easy to calculate if elevation data is available. IMHO tagging data with incline=* is the wrong solution to an important problem, and it signals the beginning of an immense and never-ending task of maintaining hard-to-verify data. It would be much better to work on a proper solution that involves designing a system for registering topographical data within street maps. Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
Roy Wallace wrote: Inclines are easy to calculate if elevation data is available - that's a big if, isn't it? Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. hard-to-verify data - I don't see why incline=* is any harder to verify than ele=* - as you said yourself, if you have one you can calculate/verify the other... The fact that there's a lot of unreliable and hard-to-verify data is no good argument for adding more. It would be much better to...design a system for registering topographical data - sounds good, go for it. But I don't see a problem with using incline=* in the meantime. Incline tagging is useless unless a consumer of this data can count on it being generally available. A driver might find herself on a steep incline when expecting a flat one, just because it wasn't tagged. IMHO it is much more productive to spend time working out some system that would allow us to compute inclines automatically on the whole dataset. That would give you the desired data all over the world and not just in your local area. Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
--- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. I doubt most GPS traces would be useful for this kind of thing, most vertical GPS data is +/- 10m under the best possible conditions, usually I seem to be +/- 20m most of the time, and it's not a stable 20m diff it jumps about just like GPS positions do. You'd need a GPS with an altimeter, or a stand alone altimeter, to do this kind of elevation differences to get accuracy better than up/down. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
John Smith wrote: --- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. I doubt most GPS traces would be useful for this kind of thing, most vertical GPS data is +/- 10m under the best possible conditions, usually I seem to be +/- 20m most of the time, and it's not a stable 20m diff it jumps about just like GPS positions do. You'd need a GPS with an altimeter, or a stand alone altimeter, to do this kind of elevation differences to get accuracy better than up/down. Right, but when making differences the error will become much less significant. As you know, the GPS device reliably tracks your relative movements, although the absolute position might be in error. When subtracting two positions from each other, the absolute positioning error will disappear. In addition, for many traces there will be multiple measurements, which will give a much better determination of the gradient. Thirdly, time is on our side, because as tech develops, GPS devices become much more accurate... think Galileo etc. Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On 22 Aug 2009, at 11:48, John Smith wrote: --- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. I doubt most GPS traces would be useful for this kind of thing, most vertical GPS data is +/- 10m under the best possible conditions, usually I seem to be +/- 20m most of the time, and it's not a stable 20m diff it jumps about just like GPS positions do. You'd need a GPS with an altimeter, or a stand alone altimeter, to do this kind of elevation differences to get accuracy better than up/ down. Remember at last years osm birthday bash we were beside the Thames just above sea level and the 20 GPSs in the group were giving a variation of around 200 metres if I remember correctly. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
--- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: When subtracting two positions from each other, the absolute positioning error will disappear. In addition, for many traces there will be multiple measurements, which will give a much better determination of the gradient. I disagree and I urge you to test this speculation out with 6-10 GPS devices and a hill and see what the results are, I doubt you would get any where near as accurate as you are assuming. Thirdly, time is on our side, because as tech develops, GPS devices become much more accurate... think Galileo etc. How many birds are in the sky now? Still 1 or did they put a second one up? You would have had better of talking about the Russian version of GPS, at least it has numerous sats in the sky even if they don't have enough for GPS type coverage. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Sat, 22 Aug 2009, Morten Kjeldgaard wrote: Right, but when making differences the error will become much less significant. As you know, the GPS device reliably tracks your relative movements, although the absolute position might be in error. not vertically because the actual device i own actually checks for a change in atmospheric pressure and does not calculate the height from the satellite data at short intervals so anyone using a Garmin etrex vista cx or similar device cannot provide height data which accurately tells you even if you are going up or down a hill at cycling speed - i've watched it when touring and you can either go up when you are going down or make huge jumps suddenly. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/22 Mike Harris mik...@googlemail.com: I'm with Martin on this one - up/down is better than nothing and is useful in its own right on steps for example. actually I wrote that it's IMHO not needed for steps: I draw them from down to up, they already have their direction. This is IMHO the natural way of doing it (as it is done like this worldwide in architecture, and I'm an architect ;-) ). I don't see much of a benefit for ways either, but I agree that ele-nodes have their own problems, and therefore the incline-tag on ways could at least indicate some kind of inclination (probably you could use this in hilly city centres, where SRTM is not sufficient, to avoid inclinations on bike or something like this). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/22 John Smith delta_foxt...@yahoo.com: --- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. I doubt most GPS traces would be useful for this kind of thing, most vertical GPS data is +/- 10m under the best possible conditions, usually I seem to be +/- 20m most of the time, and it's not a stable 20m diff it jumps about just like GPS positions do. You'd need a GPS with an altimeter, or a stand alone altimeter, to do this kind of elevation differences to get accuracy better than up/down. +1. E.g. the widespread 60 CSx from a well known manufacturer offers this, but (I guess) almost noone does a calibration before every log (at least I almost never do). That's why absolute elevation is not reliable, but the relative data (i.e. difference from one junction to another) is still highprecision compared to GPS-elevation. I wonder if some smart programmer could use this in some way for OSM. Provided you have some reliable height-points, e.g. from public survey, mountain-tops, other official signs, you could use this relative data to calculate also the intermediate nodes. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Escalators and Travalators
http://wiki.openstreetmap.org/wiki/Proposed_features/Escalator I'm trying to work out how to tag Escalators I'm not sure the current tagging it clear, or even partially useful. This ties in Greatly with the long running Path discussion.. There seams to be no clear way to tag Moving Walkways or Travelators these are Esclators without steps, so the current tagging steps with an extra tag just does not work, spouse you could tag a path, but that just makes it worse. one_way would seam to make as much sence as escalator_dir currently, and maybe this could be unified. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Escalators and Travalators
Peter Childs wrote: http://wiki.openstreetmap.org/wiki/Proposed_features/Escalator I'm trying to work out how to tag Escalators I'm not sure the current tagging it clear, or even partially useful. I wouldn't call this current tagging. That page is a proposal in draft state, i.e. its not even in the please look at my proposal, try it and comment state (aka RFC). So if we find something better, we can just use that instead. There seams to be no clear way to tag Moving Walkways or Travelators these are Esclators without steps, so the current tagging steps with an extra tag just does not work, spouse you could tag a path, but that just makes it worse. I believe the best way to solve this is to create a new top-level (that is, highway) value for all variants of conveyor transport. So, for example, we could do: highway = conveyor conveyor = escalator / travelator incline = up / down / percentage (nothing for horizontal travelators) If required also something like: conveyor:direction = forward (default) / backward / on_demand Using a highway value is justified because applications that don't know about this kind of feature would use it wrong anyway (e.g. route in the wrong direction). Would that solution work? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On 22/08/2009, at 13.14, John Smith wrote:
When subtracting two positions from each other, the
absolute positioning error will disappear.
In addition, for many traces there will be multiple
measurements, which will give a much better determination of
the gradient.
I disagree and I urge you to test this speculation out with 6-10 GPS
devices and a hill and see what the results are, I doubt you would
get any where near as accurate as you are assuming.
What kind of accuracy do you want? We are talking about people wanting
to tag incline={up, down}. GPS elevation differences are certainly
good enough to make that binary classification, especially if the
incline is one that matters.
Should every sorry GPS trace be used? Perhaps as a quick-and-dirty
start, but you are right, better and more accurate data is needed.
People who care about these things in a particular area could
certainly arrange to get accurate gpx data with an altimeter equipped
GPS.
In addition, we have access to topographical data many places, a fact
which has not been mentioned in this thread. This data can also be
used to derive elevation gradients of roads.
I realize it wont be possible to compute elevation gradients tomorrow,
but why not plan ahead? Who would've thought a few years ago that the
project would be so far advanced? Wouldn't you rather have nodes on a
way with incline=7% than incline=up? Wouldn't it be better to get
this data from a database lookup than from manual tagging?
Cheers,
Morten
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
--- On Sun, 23/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: I realize it wont be possible to compute elevation gradients tomorrow, but why not plan ahead? Who would've thought a few years ago that the project would be so far advanced? Wouldn't you rather have nodes on a way with incline=7% than incline=up? Wouldn't it be better to get this data from a database lookup than from manual tagging? I doubt anyone is disagreeing, however up/down is like tagging highway=road, it's just a rough reference. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Escalators and Travalators
2009/8/22 Tobias Knerr o...@tobias-knerr.de: Peter Childs wrote: http://wiki.openstreetmap.org/wiki/Proposed_features/Escalator I'm trying to work out how to tag Escalators I'm not sure the current tagging it clear, or even partially useful. I wouldn't call this current tagging. That page is a proposal in draft state, i.e. its not even in the please look at my proposal, try it and comment state (aka RFC). So if we find something better, we can just use that instead. There seams to be no clear way to tag Moving Walkways or Travelators these are Esclators without steps, so the current tagging steps with an extra tag just does not work, spouse you could tag a path, but that just makes it worse. I believe the best way to solve this is to create a new top-level (that is, highway) value for all variants of conveyor transport. So, for example, we could do: highway = conveyor conveyor = escalator / travelator incline = up / down / percentage (nothing for horizontal travelators) If required also something like: conveyor:direction = forward (default) / backward / on_demand Using a highway value is justified because applications that don't know about this kind of feature would use it wrong anyway (e.g. route in the wrong direction). Would that solution work? Tobias Knerr Sounds good to me I was not trying to get discussion and work out what was right and could only find something flaky on the wiki Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/22 John Smith delta_foxt...@yahoo.com: --- On Sun, 23/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: I realize it wont be possible to compute elevation gradients tomorrow, but why not plan ahead? Who would've thought a few years ago that the project would be so far advanced? Wouldn't you rather have nodes on a way with incline=7% than incline=up? Wouldn't it be better to get this data from a database lookup than from manual tagging? I doubt anyone is disagreeing, however up/down is like tagging highway=road, it's just a rough reference. I'm tempted to say gradient needs tagging, this can often be got off road signs. but I don't see why we can't tag any way with a gradient. This is also needed for steps and escalators. The issue is that it can't really be derived from elevation data as ways often go at an angle (to reduce gradient) or are built out from the land on man made structures. Some bridges my cause an incline which may need taging, ie hump backed bridges. Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Changes to Key:access wiki page
hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. * Transportation modes The transportation mode hierarchy picture is replaced by a simple outline, because the picture was not integrated in the text and too small to read on the page itself (could both be fixed), and having to figure out how to modify the picture complicates editing of this wiki page. The hierarchy is however the only definition of several transportation mode categories so quite important. IMHO the picture can be re-added but not replace the outline. Some transportation modes were listed in two unrelated categories. This needlessly complicates determining the correct tags for a real-world situation. Specifically, the meaning of access tags becomes very unclear if they belong to unrelated categories. There was apparently a good reason for doing this but I have not found a clear explanation. (Note that *=agricultural is not necessarily defined by this hierarchy, only tags like agricultural=no.) Added a separate tag for cars, because AFAICT any routing app computing routes for cars uses this transportation mode. If routing would be done for 'motorcar', ways tagged as hazmat=no, for example, could not be used because the motorcar *could* be a hazmat vehicle. Maybe the actual tag is not needed, in which case the description can stay but the tag removed. BTW what is a hov? Added a tag for low performance mopeds, because in some countries they are by law neither a bicycle nor a true moped. Separated land (road), water, and rail based transportation because they can be treated separately(?). * Direction specific restrictions I listed :backward and :forward postfixes for access keys but apparently forgot explicit descriptions. The examples should be enough for now. Some roads (around here at least) have complicated oneway restrictions that cannot be modeled with oneway= and cycleway=opposite*. The postfixes allow specifying any restriction (yes/no/destination/etc.) for any transportation mode in either direction. I'd like to deprecate cycleway=opposite because it is used for roads that have neither a cyclelane nor a cycleway in that direction, so using a cycleway tag does not make much sense. * Evaluating access tags In order to know the meaning of a set of access tags on a way with some highway tag (in case of roads), it is necessary to define how access for each transportation mode can be computed from these tags. I added a section about this which hopefully matches current tagging practice. It does not include time-based, height, width, or weight restrictions so it is certainly not yet complete. Many of the values listed at the top of the page are also missing. The idea is that this model links tagging to routing so if it used, while currently AFAIK one needs to find out how a router computes access and tag accordingly or accept broken routing in one or more routing engines. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Sat, Aug 22, 2009 at 7:43 PM, Peter Childspchi...@bcs.org wrote: The problem with this tag is that it's about topology. up/down is like north/west or turn left/right. Like the tag is_in, it shouldn't be a tag to say where a point or a pair of points is geospatialized. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Walking Papers in Dutch and German
Hello, Walking Papers has just sprouted two localized translations, German by Jonas Krückel and Dutch by Milo van der Linden. I encourage you to try it out and report any issues to: http://github.com/migurski/paperwalking/issues It should auto-detect your browser language if applicable: http://walking-papers.org/ The site is set up for more future translations, so if there are any international users from active communities who'd like to provide a localized version in another language, I'm all ears! This also means I can finally move onto the other new feature requests, starting with additional map styles for the prints. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
Hi, it's a good thing that someone finally tries to clarify access documentation - it definitely needs some care. I agree with your reasoning to replace the image with editable content and some of your definitions (such as avoiding to put an entry into the hierarchy multiple times and separating water/land). Nevertheless, some changes require a bit of discussion, but I guess you expected this, didn't you? ;) Christiaan Welvaart wrote: Added a separate tag for cars, because AFAICT any routing app computing routes for cars uses this transportation mode. If routing would be done for 'motorcar', ways tagged as hazmat=no, for example, could not be used because the motorcar *could* be a hazmat vehicle. This reasoning is not quite valid. The restrictions for a vehicle category are affected by categories higher up in the hierarchy, not by those below. At least this is the idea behind current documentation such as http://wiki.openstreetmap.org/wiki/Computing_access_restrictions , and I don't see why we should be restricted to leaves of the category tree. Therefore, considering an automobile a generic motorcar that is affected by those restrictions applying to generic motorcars should work well, it doesn't need an own category. * Direction specific restrictions I listed :backward and :forward postfixes for access keys What you are doing here seems like picking raisins from conditional tagging and trying to handle it as a special case. I'm not sure whether you are aware of my proposal? http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags While direction may be considered as something special when constructing a routing graph (unlike most other parameters it will have different values during creation of the same routing graph; unless you are really sophisticated and use changing time, it will be the only parameter like this), it's not a special case for *evaluation*: It's just another parameter needed to get the value of a base tag for the current situation. As evaluation is the aspect that needs to be documented (routing graph creation is up to the application), I believe forward/backward shouldn't be introduced or documented separately but instead as a part of conditional tagging. * Evaluating access tags Your use of category and (transport) mode confuses me, especially as they both seem to be things that can be a key. I know from experience that it is hard to find good terms for these concepts, but maybe you can help me a bit to understand it. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - greenhouse_horticulture
Proposal for tagging land areas covered by greenhouses used for growing plants. http://wiki.openstreetmap.org/wiki/Proposed_features/greenhouse_horticulture ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On 22/08/2009 20:33, Christiaan Welvaart wrote: hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. Added a separate tag for cars, because AFAICT any routing app computing routes for cars uses this transportation mode. If routing would be done for 'motorcar', ways tagged as hazmat=no, for example, could not be used because the motorcar *could* be a hazmat vehicle. Maybe the actual tag is not needed, in which case the description can stay but the tag removed. There already is a separate tag for cars: key:motorcar. I think trying to define this as different from an automobile is confusing. Have a look at Wikipedia for example, which says they are different terms for the same thing: http://en.wikipedia.org/wiki/Automobile I think your definition of motorcar (category: motor vehicles with more than 2 wheels / more than 1 track) is confusing / wrong. goods/ hgv / psv / hazmat etc should be in the hierarchy directly below motor vehicle, not below motorcar. BTW what is a hov? I assume it's high occupancy vehicle, ie a vehicle with more than a certain number of passengers in it. In some places they are allowed to use bus lanes etc. I'd agree with most of the rest of your changes on that page. Craig ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Sat, Aug 22, 2009 at 8:35 PM, Morten Kjeldgaardm...@bioxray.au.dk wrote: hard-to-verify data - I don't see why incline=* is any harder to verify than ele=* - as you said yourself, if you have one you can calculate/verify the other... The fact that there's a lot of unreliable and hard-to-verify data is no good argument for adding more. What? The key question is if a tag is verifiable. Incline=* is just as verifiable as ele=*. It's just in a different form. The good argument for adding incline=* is that it is 1) easy to read off a sign (say, source:incline=sign), 2) provides valuable information in the meantime, while we wait for you to develop and import your ele=* solution. Incline tagging is useless unless a consumer of this data can count on it being generally available. A driver might find herself on a steep incline when expecting a flat one, just because it wasn't tagged. This is ridiculous. The absence of incline=* does not infer incline=0 - it infers that the incline is unknown/unspecified. Just as absence of ele=* doesn't infer ele=0 - it infers that the elevation is unknown/unspecified. IMHO it is much more productive to spend time working out some system that would allow us to compute inclines automatically on the whole dataset. That would give you the desired data all over the world and not just in your local area. Sounds great - but in the meantime, people will continue to tag what they see on the ground - especially on road signs - in any way they see fit. Better that incline=* is used consistently for tagging incline, in the meantime. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Max recommended size for multipolygon relation?
I have done a dataset conversion in preparation for a bulk import of an NHD coastal sub-basin in the US. One of the last river stages generated a multipolygon relation containing about 3,000 members. Is it best to break this into multiple 'bands' before importing it, or is there no performance problem with tools working with a relation containing that many polygons? Thanks, Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] xapi question
Hi, A while ago I tried to work out how to use osmxapi to extract just the highways that didn't have a name in an area, but couldn't work out how to express this. Is this possible ? or have I just been stupid ;-) thanks -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Max recommended size for multipolygon relation?
--- On Sun, 23/8/09, Mike N. nice...@att.net wrote: I have done a dataset conversion in preparation for a bulk import of an NHD coastal sub-basin in the US. One of the last river stages generated a multipolygon relation containing about 3,000 members. Is it best to break this into multiple 'bands' before importing it, or is there no performance problem with tools working with a relation containing that many polygons? Apparently there is a 1000 member per relation limit. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Sat, 22 Aug 2009 21:33:27 +0200 (CEST), Christiaan Welvaart c...@daneel.dyndns.org wrote: hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. * Transportation modes (Note that *=agricultural is not necessarily defined by this hierarchy, only tags like agricultural=no.) Not all tags in access need everey value, in many cases when specifying, yes/no/dedicated cover more than enough. Only the general access need this variety of values. BTW I know of cases which could be tagged access=private + agriculture=yes + forestry=yes. Even more appropriate is hgv=no + agriculture=yes, since many of these agricultural vehicles can have a max weight far above 3.5 tonnes, I have myself maneuvered almost 10 tonnes (tractor of 2 tonnes + cargo trailer of 0.5 tonnes + 5+ tonnes of cargo). Some roads accessing farmland are actually signed with hgv=no. Separated land (road), water, and rail based transportation because they can be treated separately(?). I do not know enough about rail transport, but having only one subkey makes it abit superflous. For additional keys for water transport, see my point on the talk page. boat= should be a master key of motorboat= and sailboat=, and add fishing_vessel= and ship= as master keys as well, all other values suggested on the talk page are written hierchally under ship= Yes, there is a big point in separating boats and ships, just as separating mopeds and hgv. * Direction specific restrictions IMO this does not belong on access, but rather on oneway= as they are dictating special condition of the oneway key. * Evaluating access tags There is a list of national specific defaults of the access keys to highway=, I do not remember where it was now, but think the page is linked under 'See Also' Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Escalators and Travalators
2009/8/23 Tobias Knerr o...@tobias-knerr.de: I believe the best way to solve this is to create a new top-level (that is, highway) value for all variants of conveyor transport. So, for example, we could do: Is this intended to be only for human transport? I know of some quite lengthy conveyors for goods - eg coal, grain etc. There's two main types, belt and screw, and I've seen a mix of both. Escalators and travelators are both belt conveyors. I don't know if we want to try and differentiate for goods use, or just lump them together under something like conveyor=goods, type = grain/coal/gravel/etc. We certainly want to make it easy for routing programs to differentiate between goods and human ones. Stephen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
Hi! Christiaan Welvaart schrieb: I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. It is a good thing that you try to complete and clarify the page. However I must protest the way of doing it: Change the access tag page and only start a discussion on a single mailing list afterwards is not a good way to do this: - some of your best practices may not be quite as universally applicable as you think - some of your changes require discussion - which just started. But for everybody looking at the wiki, it appears your changes are approved recommendations - you are completely circumventing the proposal process, and everybody who is interested in feature changes and is watching the proposal page in order to be informed is simply excluded from the discussion. So in short: Regardless of the content: You should have created your version of the page as a seperate copy, maybe on the discussion page, announced it as a proposal and only changed the main access tag page _after_ some discussion and refinement. I believe even well-meant edits that change the meaning of established feature pages without prior discussion and bypassing everybody watching the proposals are creating chaos and are responsible for some of the confusion we are having about apparently simple tags like footway. So please, don't do it. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Nederlandstalige walking papers online!
http://walking-papers.org/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Nederlandstalige walking papers online!
Milo van der Linden wrote: http://walking-papers.org/ Ik heb nu voor het eerst een print gemaakt, om huisnummers in te kunnen vullen. We gaan zien of het voor mij werkbaar is. :) Top voor de vertaling. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] OSM server is down for maintenance this weeke nd 22-August-2009 → 23-August-2009
Oww, I had a nice detailed park to upload to OSM in Wollongong too. Ah well, I've saved my work in JOSM, and I'll upload it when it's back online, probably this Monday sometime. -- cam_...@fastmail.fm -- http://www.fastmail.fm - The way an email service should be ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] default rendering changes
I'm going through the default osm-template.xml and noticed some interesting things with respect to towns/cities. They have a number of things that will render identically in the default style sheet but might be used to more accurately tag places. They have the following things: [place] = 'city' or [place]='metropolis' and [place] = 'town' or [place]='large_town' or [place]='small_town' and [place] = 'village' or [place]='large_village' Looks like the path=* people have been busy little bees too: ([highway] = 'bridleway' or ([highway] = 'path' and [horse] = 'designated')) ([highway] = 'footway' or ([highway] = 'path' and [foot] = 'designated')) [highway] = 'cycleway' or ([highway] = 'path' and [bicycle] = 'designated') Also platforms might render by default now, not sure if they trapped all cases. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Non-UK Highway shields osm-template.xml patch
I've come up with the following patch: http://map-data.bigtincan.com/osm-template.xml-patch It does a number of things, including the SQL/mapnik config to show Australian shields and I also added section needed so (4WD Only) will render on the end of road names. It also adds a section for miniature railways and stopping boundary=administrative names from rendering I'd like to submit it but I think we need to submit SVG shields at the same time. I also added in BBQs, benches and picnic_sites, will need to pull the SVGs for those off Ash's website to upload as well. Most likely this patch will need to be broken up into section but this is a first draft so to speak. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Non-UK Highway shields osm-template.xml patch
In regards to the rendering of the Australian shields, last time I checked the bigtincan map server tiles, the blue metropolitan route shields had the text to be displayed as yellow, when they are meant to be white. Has this been fixed or known about? If not, then this problem has now been attended to. Thanks. On 22/08/2009, at 8:35 PM, John Smith wrote: I've come up with the following patch: http://map-data.bigtincan.com/osm-template.xml-patch It does a number of things, including the SQL/mapnik config to show Australian shields and I also added section needed so (4WD Only) will render on the end of road names. It also adds a section for miniature railways and stopping boundary=administrative names from rendering I'd like to submit it but I think we need to submit SVG shields at the same time. I also added in BBQs, benches and picnic_sites, will need to pull the SVGs for those off Ash's website to upload as well. Most likely this patch will need to be broken up into section but this is a first draft so to speak. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Non-UK Highway shields osm-template.xml patch
--- On Sun, 23/8/09, Luke Woolley lswool...@gmail.com wrote: In regards to the rendering of the Australian shields, last time I checked the bigtincan map server tiles, the blue metropolitan route shields had the text to be displayed as yellow, when they are meant to be white. Has this been fixed or known about? If not, then this problem has now been attended to. Thanks. I actually did notice it at one point but forgot to fix it, thanks for reminding me. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Sturt highway
--- On Fri, 21/8/09, BlueMM bluemm1975-...@yahoo.com wrote: I think this is why I am concerned about adding the addr: tags to the ref relations, is it not redundant data given that we have suburb boundaries, we know with reasonable certainty that a node is in what suburb/state/country? I A little redundancy can save a ton of CPU cycles calculating this every time, this is why tiles get cached rather than drawn on the fly for each request :) Since we're consolidating all the highway information 1 or 2 extra tags per relation will be less data in total than we started with. That said I finally figured out a suitable SQL query against pgsql/postgis to calculate it. select name from planet_osm_polygon where ST_Contains(way, ST_SetSRID(ST_Point(149.8422 * 20037508.34 / 180, ln(tan(((90 + -29.4642) * pi()) / 360)) / (pi() / 180) * 20037508.34 / 180), 900913)) That's for the point -29.4642, 149.8422, but you can use the same ST_Contains() function to compare relations with polygons so it's relatively straight forward to find out what state/country a line falls in. Once I convert the MySQL queries across to PostGIS queries the lookup times on searches should be less as a result. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-br] Import SEADE (Era Dúvidas: calça das, ruas, CEP)
Pessoal, No esforço de mapeamento de São Paulo, lembrei desse email do Vitor de fevereiro e resolvi baixar pra dar uma olhada nos dados. Realmente é uma base gigante com TODAS as ruas do município e talvez incluíndo os outros municípios da região Metropolitana. O Shapefile contem uma linha para cada de segmento de rua (um quarteirão) com os limites de numeração a esquerda e direita e CEP tambem. Infelizmente não tenho ideia de como mesclar as informações deles com o que temos já traçado - os algoritmos são mais complexos que os de importação dos municípios com certeza. Comecei uma página no wiki sobre isso: http://wiki.openstreetmap.org/wiki/Importa%C3%A7%C3%A3o_SEADE Vamos marcar um encontro para fazer um plano mais detalhado? []s 2009/2/8 Vitor George vitor.geo...@gmail.com: Apesar de não existir um sistema de busca de CEP ainda, podemos começar a definir como seriam as tags para isso, conforme o skippern sugeriu. Parece-me que alguns CEPs são diferentes para os lados esquerdo e direito das ruas, mas é preciso tirar esta dúvida. Uma coisa que tem me preocupado é a númeração de ruas. Acredito que no passo que estamos indo me mapeamento, vamos demorar muito para ter estas informações. O ideal é buscarmos base prontas, talvez de prefeituras, com estes dados. Aproveitando a deixa, conversei com Gustavo Coelho, que é o responsável por Geoprocessamento da Fundação Seade, e ele comentou que o Centro de Estudos da Metrópole oferece base gratuita dos logradouros de São Paulo, inclusive com numeração das ruas. É possível checar os dados aqui: http://centrodametropole.org.br/t_transf_bases_3.htm Não abri ainda estes dados, mas é uma opção para as pessoas que estão mapeando a Região Metropolitana de São Paulo. 2009/2/8 Aun Johnsen (via Webmail) skipp...@gimnechiske.org On Thu, 05 Feb 2009 19:42:14 -0200, Samuel Vale srcv...@minaslivre.org wrote: Em Dom, 2009-02-01 às 20:27 -0200, Arlindo Pereira escreveu: (...) Então, o que tenho usado, embora de forma subjetiva, é esse conceito. Na região que mapeio (meu bairro e arredores) noto claramente quais são as vias arteriais, coletoras e locais, e tenho mapeado com secondary, tertiary e residential, respectivamente, deixando living_street somente para aquelas ruas que crianças jogam bola, bem tranquilas, o que não é o caso de nenhuma aqui perto, infelizmente. Samuel, Claudomiro e László, vocês concordam com o posicionamento do Ulf? Sim, acho que pelo que foi conversado na thread, classificamos pela função de ligação da estrada e uso mesmo. Abraço, Samuel Algum quer atualicar o pagina http://wiki.openstreetmap.org/wiki/Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro com o chaves para mapear este? E tambem como vai adicionar o CEP no mapa? Eu acha a chave CEP=* poder usar, mas nao tem um sistema para buscar este no mapa ainda. -- Brgds Aun Johnsen via Webmail ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] OSMF
Frederik Ramm schrieb: Mein persoenliches Problem ist, dass es fuer viele Leute, besonders aus nicht-Deutschland, wie mir scheint, sehr schwer ist, das Abstrakte von dem Konkreten zu trennen. Da sagst Du ich finde, wir sollten sicherstellen, dass nicht eine einzelne Person zu viel Einfluss hat und zurueck kommt wieso, was hast Du gegen Name einer Person, zeig mir doch mal, was die in der Vergangenheit falsch gemacht haben soll. Naja, fairerweise muss man schon sagen, dass du keineswegs abstrakt angeprangert hast, sondern direkt. Ich zitiere: I am writing this to increase member participation because I feel that unless enough members participate in the election, it will be largely controlled by one single business entity - CloudMade. Ganz ehrlich - als Cloudmademitarbeiter würde ich auch erstmal komisch gucken. Die Reaktion von Steve fand ich allerdings reichlich übertrieben, aber nun ja. Ich persönlich finde, dass es ok ist - selbst wenn die meisten OSMF-Leute bei Cloudmade arbeiten. Ich verstehe den Interessenkonflikt nicht, den du hier implizit unterstellst. Cloudmade will doch sicher, dass OSM maximal gut wird - genau wie wir alle. Ich denke auch nicht, dass die Vorstellungen von maximal gut so weit auseinander liegen. Bei welchen Entscheidungen könnte denn die Frage Was ist das beste für OSM? von der Was ist das beste für CloudeMade? auseinanderliegen? Grüße Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wiki (wikimedia commons Einbettung)
Martin Koppenhoefer schrieb: wenn sich jemand findet, der weiss wie es geht, und es den anderen mitteilen will, ist das m.E. besser, als ein Link auf Wikipedia, wo die Lage aufgrund der Vielzahl der Infos sicher unübersichtlicher ist. Auf englisch und deutsch hier eingefügt: http://wiki.openstreetmap.org/wiki/Wiki_Help Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues ÖPNV-Schema - Linien(varianten )relationen
Danke fuer die schnelle Anttwort Habe noch es noch etwas erweiter und in die Tabelle eingetragen. Direkter Link: http://www.asamnet.de/~fischept/osm/oepnv.xml Wenn ich noch was veraendern oder verbessern kann gebt mir bescheid. Gruesse Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wiki (wikimedia commons Einbettung)
malenki schrieb: Martin Koppenhoefer schrieb: wenn sich jemand findet, der weiss wie es geht, und es den anderen mitteilen will, ist das m.E. besser, als ein Link auf Wikipedia, wo die Lage aufgrund der Vielzahl der Infos sicher unübersichtlicher ist. Auf englisch und deutsch hier eingefügt: http://wiki.openstreetmap.org/wiki/Wiki_Help Ich hatte es übrigens bei [1] gefunden. Fügst du bitte *unbedingt* in die Hilfe noch den Passus über die Lizenzen ein? Daß ist sehr wichtig da wir (je nach Lizenz) nicht alle Bilder von Commons verwenden dürfen! Da ich durch den CC-by-xy Lizenz Dschungel nicht wirklich durchsteige, habe ich bislang übrigens explizit nur Public Domain Bilder verwendet ... Gruß, ULFL [1] http://wiki.openstreetmap.org/wiki/Wikipedia#Using_pictures_from_Wikipedia_for_tag_description.2FMap_Features ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kontakt zum User im Bereich STENDAL
Hi ! ich habe die Straßenliste von Stendal besorgt und nun suche ich jemanden der sich dort sehr gut auskennt um eine Umgrenzungslinie definieren zu können. Es sind auch teilweise Orte gelistet die im Umfeld von Stendal sich befinden. Gruß Jan :-) Kontakt auch über User Lübeck [http://wiki.openstreetmap.org/index.php/User:L%C3%BCbeck] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verbraucherinformation: SIRF3 Bluetoo th-Maus für 20 Euro
Hallo, ein bekannter Chinawarenimporteur aus dem Südwesten verhökert gerade als Restposten eine etwas in die Jahre gekommene BT-Maus Jentro BT-GPS-8 für 19,90 plus 4,90 Versandkosten. (Sirf3, BT, verlöteter Akku, USB-Aufladung) Meiner Meinung eine gute Zweitmaus oder eine Lösung für zweiter Emfpänger mit anderem Chip/anderer Firmware/anderem Montage-Ort, um ggf. später zwischen den Tracks interpolieren zu können. http://www.pearl.de/a-PX5221-5481.shtml Kurztest: http://forum.pocketnavigation.de/thread.php?threadid=1054636 -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wiki - Featured Images hinüber ?
Hallo, wird nur bei mir die Seite http://wiki.openstreetmap.org/wiki/Featured_images mit lauter roten Template-Links angezeigt? Die deutsche Version sieht auch nicht besser aus: http://wiki.openstreetmap.org/wiki/DE:Featured_images -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kontakt zum User im Bereich STENDAL
Jan Tappenbeck wrote: Hi ! ich habe die Straßenliste von Stendal besorgt und nun suche ich jemanden der sich dort sehr gut auskennt um eine Umgrenzungslinie definieren zu können. Es sind auch teilweise Orte gelistet die im Umfeld von Stendal sich befinden. Man muss sich nich besonders gut auskennen um eine ungefähre Grenze ziehen zu koönnen. Es genügt schon wenn man dazu die freien Informationen zu dem Ort benutzt um eine ungefähre Grenze zu ziehen. Nichts anderes wurde in NRW auch gemacht um die Straßenliste auszuwerten ( http://osm.gt.owl.de/Strassenliste/map-nordrhein-westfalen.html ). Wenn die API wieder da ist, dann kann ich mal versuchen eine Grenze zu ziehen... Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder-Koordination
Am Sa, 22.08.2009, 03:25 schrieb André Reichelt: Damals bei der Aktion in der Oberpfalz hatten wir eine Arbeitsmatrix. Ich sehe in diesem Tool auch eine große Zukunft zur Qualitätskontrolle und Koordinierung. Habe diesbezüglich schon Kontakt zu Monti aufgenommen :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki - Featured Images hinüber ?
Johann H. Addicks schrieb: Hallo, wird nur bei mir die Seite http://wiki.openstreetmap.org/wiki/Featured_images mit lauter roten Template-Links angezeigt? Die deutsche Version sieht auch nicht besser aus: http://wiki.openstreetmap.org/wiki/DE:Featured_images Ohne jetzt eine genaue Ahnung zu haben ... Sieht für mich so aus, als ob da eine Style (oder was auch immer) Datei fehlt, wahrscheinlich wird die von einem der zur Zeit abgeschalteten Server (nicht) geladen. Würde ich mir aktuell keine großen Gedanken machen, sondern erst wenn die anderen Server wieder laufen ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kontakt zum User im Bereich STENDAL
Ich hoffe mal die Ausdehnung passt noch. Die ändern hier ihre Grenzen wie andere die Unterwäsche. Gruß Mirko grenze_stendal.rar Description: Binary data ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki - Featured Images hinüber ?
Am 22. August 2009 12:07 schrieb Johann H. Addicks addi...@gmx.net: Hallo, wird nur bei mir die Seite http://wiki.openstreetmap.org/wiki/Featured_images mit lauter roten Template-Links angezeigt? Die deutsche Version sieht auch nicht besser aus: http://wiki.openstreetmap.org/wiki/DE:Featured_images Bis KW 38 ist alles OK, danach nur leere Templates. Würde ich so lesen, als ob man sich für KW39-KW52 noch nicht auf ein IOTW geeinigt hätte. Grüße, jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kontakt zum User im Bereich STENDAL
Mirko Küster wrote: Ich hoffe mal die Ausdehnung passt noch. Die ändern hier ihre Grenzen wie andere die Unterwäsche. Jetzt verwirrst Du mich :-) Woher sind die Daten ? Willst Du die Relation erzeugen oder ist die etwas schon vorhanden ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki - Featured Images hinüber ?
Jens Frank schrieb: Bis KW 38 ist alles OK, danach nur leere Templates. Würde ich so lesen, als ob man sich für KW39-KW52 noch nicht auf ein IOTW geeinigt hätte. Danke... ich habe einfach nur nicht weit genug heruntergescrollt... dachte, da käme nix mehr... Schade nur, dass diese prominent verlinkte Seite so wenig DAU-kompatibel ist. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wiki (wikimedia commons Einbettung)
Ulf Lamping schrieb: Fügst du bitte *unbedingt* in die Hilfe noch den Passus über die Lizenzen ein? Daß ist sehr wichtig da wir (je nach Lizenz) nicht alle Bilder von Commons verwenden dürfen! erledigt (An und in dem Wiki darf gern jeder rumschreiben :) ) Da ich durch den CC-by-xy Lizenz Dschungel nicht wirklich durchsteige, rate mal, wer noch nicht :) Ich hoffe, dass ich die lizenzbezogenen Formulierungen richtig ausgedrückt habe. Wenn nicht: s.o. http://wiki.openstreetmap.org/wiki/Wikipedia#Using_pictures_from_Wikipedia_for_tag_description.2FMap_Features Einfacherweise hätte ein Verweis dahin genügt, wäre mir die Seite im Gedächtnis geblieben. Naja, nun hab ich mir die Arbeit gemacht... Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wiki (wikimedia commons Einbettung)
Am Samstag 22 August 2009 03:41:32 schrieb malenki: Sollte man diese Möglichkeit explizit in http://wiki.openstreetmap.org/wiki/Wiki_Help erwähnen oder darauf vertrauen, dass das irgendwo in der dort verlinkten Wikipedia-Hilfe zu finden ist? Wie wär’s wenn einerseits das in der Wiki_help beschrieben wird, aber andererseits auf der Upload-Seite [1] ein Link dorthin zeigt? So nach dem Motto: Wenn Sie stattdessen Bilder aus Wikipedia einbinden wollen, klicken Sie für eine kurze Einführung hier Nur habe ich keinen Bearbeiten-Link auf der Upload-Seite gefunden. gn8 malenki MfG, Adiac [1] http://wiki.openstreetmap.org/wiki/Special:Upload ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wiki (wikimedia commons Einbettung)
Adiac schrieb: Wie wär’s wenn einerseits das in der Wiki_help beschrieben wird, wird es mittlerweile aber andererseits auf der Upload-Seite [1] ein Link dorthin zeigt? So nach dem Motto: Wenn Sie stattdessen Bilder aus Wikipedia einbinden wollen, klicken Sie für eine kurze Einführung hier Gute Idee! Nur habe ich keinen Bearbeiten-Link auf der Upload-Seite gefunden. [1] http://wiki.openstreetmap.org/wiki/Special:Upload Ist halt eine Special:Seite, man wird wohl einen Admin kontaktieren müssen. Im SVN fand ich auf die Schnelle nichts. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wiki (wikimedia commons Einbettung)
Hallo, malenki o...@malenki.ch writes: Adiac schrieb: Nur habe ich keinen Bearbeiten-Link auf der Upload-Seite gefunden. [1] http://wiki.openstreetmap.org/wiki/Special:Upload Ist halt eine Special:Seite, man wird wohl einen Admin kontaktieren müssen. Im SVN fand ich auf die Schnelle nichts. Vielleicht suchst du folgendes: http://wiki.openstreetmap.org/wiki/MediaWiki:Uploadtext/de http://wiki.openstreetmap.org/wiki/MediaWiki:Uploadtext http://wiki.openstreetmap.org/wiki/Special:AllMessages Aber einen Wiki-Admin brauchst du trotzdem. Viele Grüße Sebastian Waschik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zu Quality Checks
Gary68 wrote: ich glaube, irgendwer hat die db schon mal auf one node ways geprüft. die sind zwar vielleicht unschön, haben aber keine weiteren auswirkungen. denke ich. Ich habe mal eine Abfrage über den ganzen Planeten gemacht. Es gibt 1740 Wege die nur aus einem Knoten bestehen. Ich habe die Liste mal hier abgelegt: http://www.stephans-server.de/osm/one-node-ways.csv Aktuell fällt mir kein Grund ein warum so ein kurzer Weg sinnvoll sein soll. Vermutlich können diese Wege gelöscht werden weil es am gleichen Knoten noch einen längeren Weg gibt. Wäre zu prüfen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserschutzgebiet
Ich denke das ganze passt in den Gefahrguttransportbereich, ich würde daher hazmat:water=* vorschlagen. In der Beschreibung ist es ausdrücklich erlaubt, verschiedene Abstuffungen einzubauen und ich denk das wäre eine. Am 11. August 2009 12:01 schrieb Florian Lohoff f...@rfc822.org: Das gibts als Sperrung: http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_269.svg hazmat:water = no traffic_sign=DE:269 oder eben nur die anzeige des Gebietes: http://de.wikipedia.org/w/index.php?title=Datei:Verkehrszeichen-Wasserschutzgebiet.png hazmat:water = permissive traffic_sign=DE:354 Da das Fahren dort erlaubt ist, aber der Fahrer besondere Vorsicht walten muss. Das angesprochene Schutzgebiet sollte natürlich trotzdem seperat eingezeichnet werden. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Siche selbst überschneidende Wege in D eutschland
habe das so wie ganz unten implementiert. muss wenn api wieder da noch testen. nächster lauf aber mit dem link dann. ciao gerhard On Fri, 2009-08-21 at 09:33 +0200, Peter Körner wrote: Peter Körner schrieb: Gary68 schrieb: Hi, habe einen kleinen Checker geschrieben, der selbst überschneidende Wege findet. Ich weiß, der OSM Inspektor macht das auch. Bei mir gibt es aber die berüchtigten Listen :-) http://wiki.openstreetmap.org/wiki/Self_intersecting_way_reports http://www.openstreetmap.org/?way=8605519 Oder so, dann sieht man direkt noch wo der Fehler ist: http://www.openstreetmap.org/?mlat=49.7730291mlon=6.6834463zoom=16way=8605519 Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserschutzgebiet
Hallo, am 22.08.2009 16:16 schrieb André Riedel: Ich denke das ganze passt in den Gefahrguttransportbereich, ich würde daher hazmat:water=* vorschlagen. In der Beschreibung ist es ausdrücklich erlaubt, verschiedene Abstuffungen einzubauen und ich denk das wäre eine. Die Beschilderung ist nicht zwangsläufig deckungsgleich mit den Wasserschutzgebieten ausgeführt. (Ich kenne einige WSG ohne Schilder und auch Beschilderungen, die nicht mit den Schutzzonen erklärbar sind.) Daher wäre eine Beschränkung auf die Schilder zu kurz gehüpft. Deshalb ist das... Das angesprochene Schutzgebiet sollte natürlich trotzdem seperat eingezeichnet werden. ... wichtig. Leider gibt es noch kein stimmiges Konzept für das Tagging. Ganz zu schweigen vom Rendern: Es muss ja das Gebiet angezeigt werden, ohne die anderen flächigen Informationen zu unterdrücken. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zu Quality Checks
Stephan Knauss wrote: Ich habe mal eine Abfrage über den ganzen Planeten gemacht. Es gibt 1740 Wege die nur aus einem Knoten bestehen. Ich habe die Liste mal hier abgelegt: http://www.stephans-server.de/osm/one-node-ways.csv Aktuell fällt mir kein Grund ein warum so ein kurzer Weg sinnvoll sein soll. Vermutlich können diese Wege gelöscht werden weil es am gleichen Knoten noch einen längeren Weg gibt. Wäre zu prüfen. Ich habe noch eine Liste abgelegt. Hier ist eine kombinierte Liste. Sie enthält noch die Wege die den Node enthalten der in einem anderen Weg der alleinige Member ist: http://www.stephans-server.de/osm/one-node-ways_contained2.zip Will da jemand dran arbeiten? Dann könnte ich das in eine hübsche HTML-Form bringen und regelmäßig updaten. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Walking Papers in Deutsch
Hi, seit heute gibt es Walking Papers in deutscher Sprache. Details zur Meldung von Fehlern und Verbesserungsvorschlägen findet ihr oben neben den Links zu den einzelnen Sprachen. Manche Texte sind bestimmt noch verbesserungsfähig, ich bin da für Vorschläge offen und werde selbst noch versuchen es besser zu machen. Ich denke das ist ein weiterer, wichtiger Schritt, um Walking Papers noch einfacher zu machen und noch mehr Leute mit dieser tollen Idee dahinter zu erreichen, jetzt könnt ihr diese Seite auch wirklich guten Gewissens jedem empfehlen ;-) Zur Zeit werden auch noch Freiwillige gesucht, die einen Druck- und Scan-Service übernehmen wollen. Die Idee dahinter ist, dass es Leute gibt, die keinen Drucker oder wohl wahrscheinlicher keinen Scanner haben und daher nicht an dem Projekt teilnehmen können. Daher gibt es von Stamen Design das Angebot, dass man ihnen einen frankierten Briefumschlag schickt und sie dann einen Ausdruck zurückschicken oder das man eine beschriftete Karte schickt und dann wird diese eingescannt. Details dazu hier (Beispielseite, evtl. mal auf Englisch umschalten): http://walking-papers.org/print.php?id=hgc6cmxn Allerdings ist dieses Angebot für Deutschland nicht so praktikabel, die Hürde einen Brief in die USA zu schicken und die damit verbundene Zeit ist sicherlich zu hoch. Bis jetzt gab es keine einzige Anfrage an Stamen in den USA, es ist also nicht zu erwarten, dass ihr überrannt werdet ;-) Falls ein Sponsor für Papier, Tinte etc. benötigt wird, kann das sicherlich auch über den Fossgis-Verein laufen, ich bin da bereits in Kontakt. Also, falls ihr Interesse habt so etwas zu tun, meldet euch bei mir und wir können dann die weiteren Details regeln. Es gibt auch keinen Zwang das für immer zu machen, falls es einen unerwarteten Ansturm gibt, kann man das sicherlich auch aufteilen bzw. wieder neue Leute finden. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Walking Papers in Deutsch
Jonas Krückel o...@jonas-krueckel.de wrote: Bis jetzt gab es keine einzige Anfrage an Stamen in den USA, es ist also nicht zu erwarten, dass ihr überrannt werdet ;-) Man könnte noch darauf hinweisen, dass man in vielen Internet-Cafes für 1 - 1,50 Euro einen Scan machen lassen kann und zur Not auch drucken. Letzteres wird aber IMHO in den hiesigen Gefilden nicht in Anspruch genommen werden müssen. So, wie es jetzt da steht, macht es es ja auch wenig Sinn. Die amerikanische Post wird keine deutschen Postwertzeichen akzeptieren, die zudem in Euro statt in Dollar bewertet sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF
Christoph Wagner freemaps@googlemail.com wrote: Frederik Ramm schrieb: Mein persoenliches Problem ist, dass es fuer viele Leute, besonders aus nicht-Deutschland, wie mir scheint, sehr schwer ist, das Abstrakte von dem Konkreten zu trennen. Da sagst Du ich finde, wir sollten sicherstellen, dass nicht eine einzelne Person zu viel Einfluss hat und zurueck kommt wieso, was hast Du gegen Name einer Person, zeig mir doch mal, was die in der Vergangenheit falsch gemacht haben soll. ... Ich verstehe den Interessenkonflikt nicht, den du hier implizit unterstellst. Cloudmade will doch sicher, dass OSM maximal gut wird - genau wie wir alle. Ich denke auch nicht, dass die Vorstellungen von maximal gut so weit auseinander liegen. Bei welchen Entscheidungen könnte denn die Frage Was ist das beste für OSM? von der Was ist das beste für CloudeMade? auseinanderliegen? Das ist wieder der Unterschied zwischen abstrakt und konkret. Deine Frage geht vom konkreten Fall Cloutmade aus. Um das abstrakte Problem - so wie ich es hier verstehe - mit einem konkreten Gegenbeispiel deutlich zu machen: Wie sähe die Sache aus, wenn beispielsweise Microsoft oder eine Gewährsfirma hier zur Diskussion stünde und unsere Arbeit vereinnahmt. Im Klartext: Es muss kein konkreter Anlass vorliegen. Ist wohl ähnlich zu verstehen, wie die Pflicht eines Politikers im öffentlichen Amt, seine Einkunftsverhältnisse offen zu legen, um sicherzustellen, dass er nicht aus fremden finanziellem Interesse seine Position ausnutzt ... und zwar auch hier, ohne dass ein konkreter Anlass vorliegt. Da ich hier neu bin und keinen Einblick in die Foundation habem, kann ich nur grundsätzlich sprechen. Allerdings findet man im Allgemeinen wenig Gehör, wenn man auf potentielle Probleme aufmerksam macht. Da wird zumeist erst dann reagiert, wenn das Kind in den Brunnen gefallen ist - sofern es dann noch möglich ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF
Tirkon schrieb: Das ist wieder der Unterschied zwischen abstrakt und konkret. Deine Frage geht vom konkreten Fall Cloutmade aus. Um das abstrakte Problem - so wie ich es hier verstehe - mit einem konkreten Gegenbeispiel deutlich zu machen: Wie sähe die Sache aus, wenn beispielsweise Microsoft oder eine Gewährsfirma hier zur Diskussion stünde und unsere Arbeit vereinnahmt. Ähm... Definiere vereinnahmt Die können sich von mir aus die gesamten Daten greifen, das in irgendeine MSN-Scheisse übernehmen und danach wie üblich herumkotzen dass sie überhaupt die Grössten sind. Wenn sie daraus dann Microsoft Streetmap (tm)(c) machen ists mir egal, solange es einen Linux-Client gibt und ich die Daten immer noch frei verwenden kann. Erst wenns wirklich vereinnahmt wird, dann bekommen die keine Daten mehr von mir - dafür wird recht schnell ein neuer Dienst aufpoppen der das wieder als OpenSource anbietet. Im Klartext: Es muss kein konkreter Anlass vorliegen. Ist wohl ähnlich zu verstehen, wie die Pflicht eines Politikers im öffentlichen Amt, seine Einkunftsverhältnisse offen zu legen, um sicherzustellen, dass er nicht aus fremden finanziellem Interesse seine Position ausnutzt ... und zwar auch hier, ohne dass ein konkreter Anlass vorliegt. Ok - Du stellst fest, dass Dein Abgeordneter von Konzern ABC gut gefüttert wird. Ich würde ihn auch nicht wählen - und zwar alleine schon aus dem Grund, weil er zu blöde ist, seine Buchführung hinreichend gut zu gestalten. Denn sowas zeugt nur von völliger Inkompetenz in allen wirtschaftlichen Bereichen incl. Buchhaltung. Bernd -- Bernd Hohmann DV Sachverständiger Gutachter Höhenstrasse 2 * 61130 Nidderau Telefon: 06187/900495 * Telefax: 06187/900493 http://www.openbc.com/go/invite/3332504.b93ac9 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF
Bernd Hohmann hohm...@harddiskcafe.de wrote: Ähm... Definiere vereinnahmt Die können sich von mir aus die gesamten Daten greifen, das in irgendeine MSN-Scheisse übernehmen und danach wie üblich herumkotzen dass sie überhaupt die Grössten sind. Ich meine damit zunächst einmal, dass sie die Foundation personell übernehmen. Wenn sie daraus dann Microsoft Streetmap (tm)(c) machen ists mir egal, solange es einen Linux-Client gibt und ich die Daten immer noch frei verwenden kann. Erst wenns wirklich vereinnahmt wird, dann bekommen die keine Daten mehr von mir - dafür wird recht schnell ein neuer Dienst aufpoppen der das wieder als OpenSource anbietet. Die Frage ist bloß, ob der neue Dienst aufgrund beschränkter finanzieller Mittel dann dagegen anstinken kann. Man sehe sich nur die Bilderdienste an. Die bekommen zigfach soviel Bilder als der Wikipedia zugeordnete Bilderdienst Wikicommons. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF
Tirkon schrieb: Erst wenns wirklich vereinnahmt wird, dann bekommen die keine Daten mehr von mir - dafür wird recht schnell ein neuer Dienst aufpoppen der das wieder als OpenSource anbietet. Die Frage ist bloß, ob der neue Dienst aufgrund beschränkter finanzieller Mittel dann dagegen anstinken kann. Man sehe sich nur die Bilderdienste an. Die bekommen zigfach soviel Bilder als der Wikipedia zugeordnete Bilderdienst Wikicommons. [x] Du willst zu Wikicommons keine Daten mehr liefern sondern zu kommerziellen Bilderdienste weil die entweder kaufen oder ablehnen - bei Wikicommons hast Du unter Umständen noch Jahrelang Leute am Arsch, die mit Dir darüber diskutieren wollen. Bernd -- Bernd Hohmann DV Sachverständiger Gutachter Höhenstrasse 2 * 61130 Nidderau Telefon: 06187/900495 * Telefax: 06187/900493 http://www.openbc.com/go/invite/3332504.b93ac9 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Robert S. osm-m...@autobahnen-europa.eu wrote: Alles was unbefestigt ist und außerhalb der geschlossenen Bebauung liegt, ist highway=track (Eine Ausnahme wärees vlt. noch, wenn es sich um eine Straße des klassifizierten Straßennetz handelt (Kreisstraße aufwärts)). Also ich wohne hier schon abgelegen. Hier mappen wir als secondary , (was dann tatsächlichlich auch eine Landesstraße ist) was in Ballungsräumen schon mit tertiary Probleme bekommen würde. Bei mancher gewidmeter Straße glaubt man bisweilen, jetzt ans Ende der Welt zu kommen, wenn man durch die Moore kurvt. Aber eine unbefestigte Kreisstraße? Gibt es so etwas wirklich? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF
Bernd Hohmann schrieb: Tirkon schrieb: Das ist wieder der Unterschied zwischen abstrakt und konkret. Deine Frage geht vom konkreten Fall Cloutmade aus. Um das abstrakte Problem - so wie ich es hier verstehe - mit einem konkreten Gegenbeispiel deutlich zu machen: Wie sähe die Sache aus, wenn beispielsweise Microsoft oder eine Gewährsfirma hier zur Diskussion stünde und unsere Arbeit vereinnahmt. Ähm... Definiere vereinnahmt Die können sich von mir aus die gesamten Daten greifen, das in irgendeine MSN-Scheisse übernehmen und danach wie üblich herumkotzen dass sie überhaupt die Grössten sind. Lernt man so eine religiöse Verblendung eigentlich heutzutage auf dem Schulhof? Wenn sie daraus dann Microsoft Streetmap (tm)(c) machen ists mir egal, solange es einen Linux-Client gibt und ich die Daten immer noch frei verwenden kann. Erst wenns wirklich vereinnahmt wird, dann bekommen die keine Daten mehr von mir - dafür wird recht schnell ein neuer Dienst aufpoppen der das wieder als OpenSource anbietet. In vielen Fällen geht es bei solchen Sachen um Kleinigkeiten, die dir selber vielleicht völlig egal sind, aber anderen den entscheidenden kleinen Nachteil bereiten. Nur mal so als Beispiel könnte außer der OSMF keiner eine Lizenzänderung durchführen, weil schlicht die Adressdaten der einzelnen Mapper nicht öffentlich sind um diese zu den Änderungen befragen zu können. Auch wenn die OSMF eine solche Anfrage an alle Mapper schickt, kann kein anderer einen Gegenvorschlag an alle losschicken (und das ist vielleicht auch ganz gut so). Es ist manchmal halt schon ganz praktisch, das kleine bisschen mehr zu wissen/können als der Mitbewerber ;-) Ich denke es gibt hier ein paar Leute, die nach solchen Geschichten wie bei CDDB halt ziemlich vorsichtig (geworden?) sind. Wenn du deine Daten also nicht dreimal eingeben willst, ist ein wenig mehr als Microsoft ist blöd als Gedankengang schon vielleicht ganz sinnvoll ... Gruß, ULFL P.S: Übrigens: Das hier die meisten die gleichen Projektziele haben halte ich mal für einen ganz großen Trugschluß :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF
Ulf Lamping schrieb: Ähm... Definiere vereinnahmt Die können sich von mir aus die gesamten Daten greifen, das in irgendeine MSN-Scheisse übernehmen und danach wie üblich herumkotzen dass sie überhaupt die Grössten sind. Lernt man so eine religiöse Verblendung eigentlich heutzutage auf dem Schulhof? Hmm.. War schon lange nicht mehr auf dem Schulhof weil meine Jüngste stark auf die Volljährigkeit zugeht. Bedaure also, dass ich keine Chance habe mit Dir mitzudiskutieren. Bernd -- Bernd Hohmann DV Sachverständiger Gutachter Höhenstrasse 2 * 61130 Nidderau Telefon: 06187/900495 * Telefax: 06187/900493 http://www.openbc.com/go/invite/3332504.b93ac9 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
Hi Tirkon, Aber eine unbefestigte Kreisstraße? Gibt es so etwas wirklich? Nur mal so auf die Schnelle zwei Kreisstraßen in MeckPomm: http://www.locr.com/photo-germany-mecklenburg-west-pomerania-rubkow-k19-13827697 http://www.locr.com/photo-germany-mecklenburg-west-pomerania-murchin-k33-13827696 http://www.locr.com/photo-germany-mecklenburg-west-pomerania-murchin-k33-13827695 Gruß, Heiko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feldweg, aber kein Schild
2009/8/23 Tirkon tirko...@yahoo.de Aber eine unbefestigte Kreisstraße? Gibt es so etwas wirklich? In Thüringen gibt es (laut einer Karte der Straßenbaubehörde) sogar noch einige unbefestigte Landesstraßen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Hi, noch ein neues Argument für das Ausschreiben von Straßennamen: Die Symbian-Software Loadstone-GPS importiert OSM-Daten und liest sie mittels Screenreader vor - Es ist eine einfache Navi-Software, die auch für Blinde funktioniert. Also wenn wir nicht demnächst für jeden Straßennamen zusätzlich einen Phonetics Tag angeben wollen, dann schreiben wir die Straßen gleich aus. Das spart jede Menge Redundanz :-) Gruß Lulu-Ann -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
lulu-...@gmx.de schrieb: noch ein neues Argument für das Ausschreiben von Straßennamen: Die Symbian-Software Loadstone-GPS importiert OSM-Daten und liest sie mittels Screenreader vor Ja und? Was bringt es, wenn ich vom Screenreader in OSM eine Hermann-Heinrich-Meierstraße vorlesen lasse, wenn auch alle Passanten die Straße nur als H.-H.-Meier-Straße kennen, weil es eben so auf dem Straßenschild steht und auch in Anschriften so geschrieben wird? Ich entsinne mich an einen DDR-Verwandtenbesuch in meiner Kindheit, bei das für die Anmeldung am Reiseziel zuständige Polizeirevier mal wieder ein anderes war, diesmal war's in der Lenin-Allee. Wegebeschreibung plus Karte gab's von den Verwandten, meine Mutter fuhr, ich sollte als Beifahrer fransen. Wir waren dann auf einer großen Ausfallstraße, aber die Leninallee ließ sich nicht finden. Und ich sah im Vorbeifahren nur, dass auf den Schildern irgendwas mit Wladimir Illinowski Allee stand (oder so ähnlich, konnte ich eben nicht so schnell lesen). Hat mich als 13jährigen intellektuell etwas überfordert... Will sagen: Ob ausgeschrieben oder abgekürzt, das ist völlig egal. Im Stadtplan sollte es schon so geschrieben stehen wie man es auf den Straßenschildern lesen kann! Dann kommen auch Auswärte mit eingeschränkter Allgemeinbildung damit zurecht. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues ÖPNV-Schema - Linien(varianten )relationen
Marcus Koerner marcus.koer...@googlemail.com wrote: Habe noch es noch etwas erweiter und in die Tabelle eingetragen. Direkter Link: http://www.asamnet.de/~fischept/osm/oepnv.xml Hallo Markus, ich habe keine Ahnung von XML. Darum sagt mir dise Buchstabenwüste auch nicht so viel. Sieht aus, wie irgendein programmiertes Formular für das neue Schema, wobei leere Tags automatisch gelöscht werden. Aber wie verwendet man mit dem Teil? Könntest Du mir vielleicht die Relationen einer Buslinie nennen, die Du nach dem neuen ÖPNV-Schema getaggt hast? Günstig wäre eine Linie, die möglichst eine Teilstrecke unbegleitet und eine andere begleitet von anderen Linien zurücklegt. War auch eine Buslinie mit Varianten in der Streckenführung dabei? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
On Sun, Aug 23, 2009 at 03:24:43AM +0200, Johann H. Addicks wrote: Was bringt es, wenn ich vom Screenreader in OSM eine Hermann-Heinrich-Meierstraße vorlesen lasse, wenn auch alle Passanten die Straße nur als H.-H.-Meier-Straße kennen, weil es eben so auf dem Straßenschild steht und auch in Anschriften so geschrieben wird? Ich entsinne mich an einen DDR-Verwandtenbesuch in meiner Kindheit, bei das für die Anmeldung am Reiseziel zuständige Polizeirevier mal wieder ein anderes war, diesmal war's in der Lenin-Allee. Wegebeschreibung plus Karte gab's von den Verwandten, meine Mutter fuhr, ich sollte als Beifahrer fransen. Wir waren dann auf einer großen Ausfallstraße, aber die Leninallee ließ sich nicht finden. Und ich sah im Vorbeifahren nur, dass auf den Schildern irgendwas mit Wladimir Illinowski Allee stand (oder so ähnlich, konnte ich eben nicht so schnell lesen). Hat mich als 13jährigen intellektuell etwas überfordert... Nicht alles was hinkt ist ein vergleich - Die allermeisten Namen sind abgekuerzt - In deinem fall steht etwa ganz anderes da - Da ist nicht abkuerzung sondern synonymbildung. Und davon redet hier keiner. Und nur weil auf dem Straßenschild A.-v.-D.-Hülshoff steht kennen das nicht die Anwohner als A Punkt Minus vau punkt - Deee Punkt Minus Hülshoff Straße sondern als Annette-von-Droste-Hülshoff Straße und das bekommen auch Menschen aus anderen Kulturkreisen hin das ein Anfangsbuchstabe Punkt eine abkuerzung ist. Will sagen: Ob ausgeschrieben oder abgekürzt, das ist völlig egal. Im Stadtplan sollte es schon so geschrieben stehen wie man es auf den Straßenschildern lesen kann! Dann kommen auch Auswärte mit eingeschränkter Allgemeinbildung damit zurecht. Das haette dir in diesem fall nicht geholfen weil das was auf dem Straßenschild stand abwich vom allgemeinen Sprachgebrauch. Und dann bist du erst recht aufgeschmissen... D.h. es gibt notwendigkeit fuer moegliche 10-20 Namen. 1...n Straßenschilder 1...n Schreibweisen aus dem Straßenverzeichnissen der Stadt 1...n Allgemeiner Sprachgebrauch Flo -- Florian Lohoff f...@rfc822.org Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Relation per continuità tra due wa y
On Sat, 22 Aug 2009 01:06:38 +0200, Gian Paolo wrote: Ciao David, Ciao, La relazione route indica che i suoi membri compongono un percorso di qualche tipo. Una strada io la vedo anche come percorso... Ricordo di aver letto che la tendenza era di escluderne l'uso per la semplice unione dei tratti di una via Hai qualche link al riguardo? ma anche estendendo l'uso a questo caso questa relazione non indica nulla di cosa avviene nei punti di congiunzione: potrebbe trattarsi di incroci con stop, dare precedenza o addirittura una strada senza alcuna interruzione (ad esempio nel punto in cui cambia il limite di velocità) Nel caso di dare precedenza, non ho in mente alcun tag OSM che potrebbe aiutare (magari esiste ma mi sfugge). Nel caso di stop, lo stop non è *mai* sul punto di intersezione tra due way (i.e. al centro dell'incrocio). È per questo che io ho mappato gli stop come punti subito *prima* degli incroci. (Non riesco ad aprire osm.org, credevo la manutenzione fosse solo per api.osm.org...) [..] Il nome però non può essere un criterio: ci sono casi in cui ad esempio per proseguire dritto su una strada con stesso nome devi fermarti e dare la precedenza mentre la svolta non presenta interruzioni. Forse questo si può risolvere con la Relation:type=restriction? Anche il diverso tipo di way non è detto che corrisponda alla situazione dell'incrocio e comunque rimangono i casi di way con stessa classificazione. Ok, ci siamo, IMHO la relazione route va più che bene qui. Ma sono aperto ad altre interpretazioni (anche se mi scoccerebbe cambiare le n-mila relation route che ho creato :-)) http://wiki.openstreetmap.org/wiki/Relation:stop (non esiste) ho sbagliato il link. Prova con questo: http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type=stop Letto, ed è pur vero che nella pagina dello Stop si parla di possibili relazioni anche lì: http://wiki.openstreetmap.org/wiki/Tag:highway=stop Forse dovremmo discuterne un po', magari in un thread separato :-) Come detto, per me è chiaro. Se un navigatore ti dice prosegui quando dovresti svoltare, è un problema suo, non dei dati :-) vorrei però inserire dei dati che permettano al software di stabilire l'eventuale indicazione da dare. Non si tratta di una indicazione finalizzata al navigatore: è comunque un attributo fisico (segnaletica orizzontale e verticale) che al momento non credo sia adeguatamente descritto dai dati Uhm? Come struttureresti una simile relazione? Fa' un esempio. Anche se il fine non è esattamente lo stesso credo che potrebbe essere una generalizzazione di http://wiki.openstreetmap.org/wiki/Relations/Proposed/Right_of_way Ok, vedo che non c'è proprio nulla di usabile :-), possiamo discuterne, magari nel thread separato riguardante gli stop di cui sopra ;) dato che la presenza di uno stop o di un dare la precedenza implica un'interruzione. Dovrebbero però essere aggiunti anche altri casi, in particolare quello per il caso di strada che continua senza soluzione dato che il caso di default sarebbe comunque la presenza di un qualche tipo di incrocio. Inoltre se la via su cui svoltare è a senzo unico non sarà presente un qualche tipo di precedenza ad indicare implicitamente il cambio di strada. I membri credo dovrebbero essere la/le way di provenienza from, quella/le di destinazione to e il punto di congiunzione via; un apposita proprietà della relazione servirà per indicare se si tratta di strada continua, stop, precedenza, precedenza a destra (caso default?), svolta generica o altro. Non ho capito: strada continua? Se non c'è incrocio, non c'è motivo di una relazione tipo di incrocio (come dici tu stesso:) Per quanto riguarda il type credo che dovrebbe essere un termine per rendere l'idea di tipo di incrocio type=junction? type=intersection? Ciao, David (accaldato, quindi mi scuso in anticipo se non ho capito qualcosa / ho sparato qualche panzana) -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Relation per continuità tra due wa y
Il 22/08/2009 16:56, David Paleino ha scritto: Nel caso di stop, lo stop non è *mai* sul punto di intersezione tra due way (i.e. al centro dell'incrocio). È per questo che io ho mappato gli stop come punti subito *prima* degli incroci. Soluzione che a me non piace per niente. Tempo fa avevo proposto di mettere il tag direttamente sulla way[1,2]: soluzione semplice, efficace, pulita. Pur non avendo alcuna ufficialità, quest'idea ha avuto un più che discreto successo, anche se praticamente solo nel nostro paese[3,4]. Forse sarebbe il caso di promuovere questa chiave, e cercare di rientrare nell'ufficialità. Purtroppo non ho il tempo per seguire la cosa; se qualcuno fosse interessato, gli passo fin d'ora la palla con grande piacere :-) [1] http://wiki.openstreetmap.org/wiki/Key:stop [2] http://wiki.openstreetmap.org/wiki/IT:Key:stop [3] http://tagwatch.stoecker.eu/Italy/En/keystats_stop.html [4] http://tagwatch.stoecker.eu/Europe/En/keystats_stop.html -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Relation per continuità tra due wa y
On Sat, 22 Aug 2009 17:45:02 +0200, Carlo Stemberger wrote: Il 22/08/2009 16:56, David Paleino ha scritto: Nel caso di stop, lo stop non è *mai* sul punto di intersezione tra due way (i.e. al centro dell'incrocio). È per questo che io ho mappato gli stop come punti subito *prima* degli incroci. Soluzione che a me non piace per niente. Sarai però d'accordo con me che il segnale di stop non è (in alcun caso!) al centro dell'incrocio, cosa che invece l'intersezione tra due (o più) way indica. Tempo fa avevo proposto di mettere il tag direttamente sulla way[1,2]: soluzione semplice, efficace, pulita. Sono d'accordo, mi pare più pulita. Pur non avendo alcuna ufficialità, quest'idea ha avuto un più che discreto successo, anche se praticamente solo nel nostro paese[3,4]. Come non è ufficiale? http://wiki.openstreetmap.org/wiki/Key:stop Non vedo alcun Proposed_features nell'URL :-) Forse sarebbe il caso di promuovere questa chiave, e cercare di rientrare nell'ufficialità. Purtroppo non ho il tempo per seguire la cosa; se qualcuno fosse interessato, gli passo fin d'ora la palla con grande piacere :-) Se non lo è già ufficiale (visto lo schema dell'url), lo metto nella mia to-do della proposed features (o, quantomeno, discuterne su talk@). Inoltre bisognerebbe inserirlo nelle varie highway=* (o nelle Map features) Ciao, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] key:stop [ERA: Relation per continui tà tra due way]
Il 22/08/2009 18:02, David Paleino ha scritto: Sarai però d'accordo con me che il segnale di stop non è (in alcun caso!) al centro dell'incrocio, cosa che invece l'intersezione tra due (o più) way indica. Certamente. Questo è appunto il problema che si ha quando si assegna il tag ad un nodo: non va bene in ogni caso. Tempo fa avevo proposto di mettere il tag direttamente sulla way[1,2]: soluzione semplice, efficace, pulita. Sono d'accordo, mi pare più pulita. Grazie :-) Come non è ufficiale? http://wiki.openstreetmap.org/wiki/Key:stop Non vedo alcun Proposed_features nell'URL :-) Beh, quella pagina l'ho scritta io. Non c'è stata alcuna votazione. Infatti non è in map features. Se non lo è già ufficiale (visto lo schema dell'url), lo metto nella mia to-do della proposed features (o, quantomeno, discuterne su talk@). Inoltre bisognerebbe inserirlo nelle varie highway=* (o nelle Map features) Sulla map feature italiana c'è un link alla pagina key:stop (dicendo che highway=stop è deprecato). Sono molto contento che te ne occupi tu. Solo una cosa: cerchiamo di restare compatti come lista italiana, e fissiamo dei punti fermi su come muoverci esattamente, magari sulla tua pagina personale sul wiki: finora non ho fatto niente proprio perché non volevo fare passi falsi (e non avevo il tempo per occuparmene seriamente). Insomma, muoviamoci solo quando siamo sicuri che la proposta venga accettata. Bisognerebbe magari prima riflettere se lo stesso schema possa essere applicato anche ai segnali di precedenza ed ai semafori: a naso direi di sì. Grazie! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] key:stop [ERA: Relation per continui tà tra due way]
On Sat, 22 Aug 2009 18:23:22 +0200, Carlo Stemberger wrote: Il 22/08/2009 18:02, David Paleino ha scritto: Come non è ufficiale? http://wiki.openstreetmap.org/wiki/Key:stop Non vedo alcun Proposed_features nell'URL :-) Beh, quella pagina l'ho scritta io. Non c'è stata alcuna votazione. Infatti non è in map features. Ahi ahi ahi! :-) Se non lo è già ufficiale (visto lo schema dell'url), lo metto nella mia to-do della proposed features (o, quantomeno, discuterne su talk@). Inoltre bisognerebbe inserirlo nelle varie highway=* (o nelle Map features) Sulla map feature italiana c'è un link alla pagina key:stop (dicendo che highway=stop è deprecato). Ok, anche se prima dovremmo discuterne un attimo :-) Sono molto contento che te ne occupi tu. Anche per me il tempo scarseggia, però ho le serate praticamente libere, quindi posso dedicarmici un po'. Solo una cosa: cerchiamo di restare compatti come lista italiana, e fissiamo dei punti fermi su come muoverci esattamente, magari sulla tua pagina personale sul wiki: finora non ho fatto niente proprio perché non volevo fare passi falsi (e non avevo il tempo per occuparmene seriamente). Insomma, muoviamoci solo quando siamo sicuri che la proposta venga accettata. Ok. Bisognerebbe magari prima riflettere se lo stesso schema possa essere applicato anche ai segnali di precedenza ed ai semafori: a naso direi di sì. Per i segnali di precedenza, penso sia necessaria una relation (anche se non c'è nulla di delineato, aggiungo anche questo in TODO). Per i semafori non saprei, devo pensarci un attimo su :-), anche se tempo fa rimasi affascinato da: http://wiki.openstreetmap.org/wiki/Proposed_features/Set_of_Traffic_Signals anche se l'idea di disegnare un'area a casaccio NON mi garba affatto. Piuttosto unire tutti gli highway=traffic_signals in una relazione, questo sì. Comunque, ecco: http://wiki.openstreetmap.org/wiki/User:Hanska#TODO lavorerò nel tempo libero a queste tre cose :-) Ciao, David (che a Settembre, appena tornerà a casa, si rimetterà al lavoro su stats.osm.it) -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] key:stop [ERA: Relation per continui tà tra due way]
Il 22/08/2009 19:00, David Paleino ha scritto: Ok, anche se prima dovremmo discuterne un attimo :-) Se ne era già discusso a suo tempo (scava nella mailing list novembre 2008), ed era sembrata a tutti una buona idea. Comunque, ecco: http://wiki.openstreetmap.org/wiki/User:Hanska#TODO lavorerò nel tempo libero a queste tre cose :-) Ottimo! -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Elezione Board Fondation
Ci sono novità , probabilmente abbiamo un membro italiano nella Fondation di OSM http://wiki.openstreetmap.org/wiki/Foundation/AGM09/Election_to_Board Complimenti a Simone, stanno ancora verificando i voti , ma la cosa è quasi definitiva incrociamo le dita Roberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Elezione Board Fondation
On Sat, 22 Aug 2009 21:04:25 +0200, Roberto Navoni wrote: Ci sono novità , probabilmente abbiamo un membro italiano nella Fondation di OSM http://wiki.openstreetmap.org/wiki/Foundation/AGM09/Election_to_Board \o/ \o/ \o/ Complimenti a Simone, stanno ancora verificando i voti , ma la cosa è quasi definitiva incrociamo le dita Simone, offri da bere a tutti adesso? :-) David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-co] Programa para georeferenciar imagenes en windows
Hola Maperos. Este es un programa para georreferenciar fotografias para los que usan Windows, por favor si alguien lo prueba que nos cuente como le va. http://www.robogeo.com/home/download.asp salu2 -- 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
Re: [Talk-es] [Fwd: [OSM-dev] REMINDER: Server Down Time - 22nd to 23rd August 2009]
El 22 de agosto de 2009 01:28, Jaume Figuerasjaume.figue...@masafi.cat escribió: Hola, por si no lo sabíais, este fin de semana no funcionarán los servidores de OSM. Muchas gracias por el aviso. Como dicen, aprovechad para recoger muchas trazas :-) -- Jynus http://jynus.com ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-ca] Canada Import Status Chart
Hi all, I just about have all of the Data that has been imported in Canada listed on the chart. (just a bit of Ontario, and the stats of my southern Vancouver Island CanVec import, and the status of Yan's GeoBaseNHN import) Hopefully that will get done in the next couple days. I'd like to proposed that we remove that chart (once im all done), then maintain this Google Docs chart. Does anyone have any objections to this? Cheers, Twitter: @Acrosscanada Facebook: http://www.facebook.com/sam.vekemans ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Brno v OSM? 60%
[1] http://web.mvcr.cz/adresa/b/brno/index.html [2] OSM way orezane na hranice mesta Brna. Nad popisnou slozkou udelan SQL dotaz: SELECT COUNT(highway) WHERE 1 GROUP BY name. Zaokrouheno na cele desitky. Je k tomu nejaky skript, ze bych to zkusil i pro Prahu a jina mesta a pripadne by se to cas od casu mohlo nejak poustet poloautomaticky? *** skript neni, delal jsem to v desktop sw comi prisel pod ruku behem poucnych historek jednoho kolegy. Sic v PgSQL by to nemel byt problem. Zadrhel vsak tkvi v tom, ze jsem pro hranice obce pouzil komercni dataset. Nase hranice katastralnich uzemi stale cekaji na dodo... hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Zeleznicni prejezdy
Ahoj, Sprava zeleznicni dopravni cesty od 1.srpna spustila nove cislovani vsech zeleznicnich prejezdu v CR [1] za ucelem snazsi identifikace pri mimoradnych udalostech, pricemz data se daji taky stahnout [2] vcetne zemepisnych souradnic. Podle vyjadreni zastupce SZDC [3] to vypada, ze chteji (logicky) tyto informace co nejvic propagovat, tak by snad nebyl problem ziskat souhlas k pouziti. Otazka zni, zda je zajem o nejaky import, pripadne jak ho provest. PT [1] http://www.szdc.cz/pro-media/tiskove-zpravy/cislovani-prejezdu.html [2] http://www.prejezdy.eu/keStazeni.php [3] http://www.rozhlas.cz/radionaprani/archiv/?p_po=3897 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Zeleznicni prejezdy
Ahoj, Dne 22. srpen 2009 14:01 Pavol Trenkler d...@palko.sk napsal(a): Ahoj, Sprava zeleznicni dopravni cesty od 1.srpna spustila nove cislovani vsech zeleznicnich prejezdu v CR [1] za ucelem snazsi identifikace pri mimoradnych udalostech, pricemz data se daji taky stahnout [2] vcetne zemepisnych souradnic. Podle vyjadreni zastupce SZDC [3] to vypada, ze chteji (logicky) tyto informace co nejvic propagovat, tak by snad nebyl problem ziskat souhlas k pouziti. Otazka zni, zda je zajem o nejaky import, pripadne jak ho provest. zajem urcite je :). Pokud nekdo domluvi pravni otazky tak se importu rad ujmu. -- S pozdravem/Best regards Bc. Ondrej Novy Email: n...@ondrej.org Jabber: on...@njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Brno v OSM? 60%
Jestliže existuje databáze kú, která byla mj. použita jako podklad pro mapky okresů a obcí na Wikipedii s tím, že jde o PD-Czech-gov (dílo státních úřadů nepodléhající právní ochaně), nedala by se tatáž databáze (shx, dbf a dwg) použít pro OSM? JD Dne Sat, 22 Aug 2009 17:22:10 +0200 Frettie fret...@gmail.com napsal/-a: Já vím, že se to z licenčních důvodů nesmí, ale nejsou ty hranice v komerčních datasetech stejné jako ve všech ostatních? Není to pomalu jako dát licenci na vzduch? :/ 2009/8/22 hanoj eha...@gmail.com: [1] http://web.mvcr.cz/adresa/b/brno/index.html [2] OSM way orezane na hranice mesta Brna. Nad popisnou slozkou udelan SQL dotaz: SELECT COUNT(highway) WHERE 1 GROUP BY name. Zaokrouheno na cele desitky. Je k tomu nejaky skript, ze bych to zkusil i pro Prahu a jina mesta a pripadne by se to cas od casu mohlo nejak poustet poloautomaticky? *** skript neni, delal jsem to v desktop sw comi prisel pod ruku behem poucnych historek jednoho kolegy. Sic v PgSQL by to nemel byt problem. Zadrhel vsak tkvi v tom, ze jsem pro hranice obce pouzil komercni dataset. Nase hranice katastralnich uzemi stale cekaji na dodo... hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- Tato zpráva byla vytvořena převratným poštovním klientem Opery: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Brno v OSM? 60%
Já vím, že se to z licenčních důvodů nesmí, ale nejsou ty hranice v komerčních datasetech stejné jako ve všech ostatních? Není to pomalu jako dát licenci na vzduch? :/ *** Vsechny hranice s trochou stesti polohopisne stejne jsou, ale i ty puvodni ramuje licence [1]. Zadne ostatni jsem nikde nenasel. Najdou se snad nejake v podobe vektorove a georeferencovane a PD? Jestliže existuje databáze kú, která byla mj. použita jako podklad pro mapky okresů a obcí na Wikipedii s tím, že jde o PD-Czech-gov (dílo státních úřadů nepodléhající právní ochaně), nedala by se tatáž databáze (shx, dbf a dwg) použít pro OSM? *** Co jsem na Wikipedii namatkou dival nepracuje se s mapami uplne korektne, vzhledem ke zvyklostem na OSM, kopirovanim z cizich map [2], [3]. *** Jakysi odkaz na PD-Czech-gov jsem nasel zde[4], ale skutecny zdroj? Mozna toto [6] podle [5]? Nenasel jsem zdroj... PS: dodelat hranice katastralnich uzemi z wms.cuzk.cz je jen otazka OCR 13 000 dvouradkovych textu (nazev a kod) a docistit... ha hanoj [1] https://geoportal.cuzk.cz/eshop/Cenik/Cenik.rtf [2] http://cs.wikipedia.org/wiki/Soubor:TR3.1_Trebic_transport.svg [3] http://cs.wikipedia.org/wiki/Soubor:Kojetice_map.svg [4] http://commons.wikimedia.org/wiki/File:CoA_CZ_regions.png [5] http://cs.wikipedia.org/wiki/Wikipedie:Jak_%C4%8D%C3%ADst_infoboxy_%C4%8Desk%C3%BDch_s%C3%ADdel [6] http://vdb.czso.cz/xml/mos.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Re : [Nouveaux] Contribution via une application Android
Le samedi 22 août 2009, Emilie Laffray a écrit : Je n'ai jamais parler de m'en foutre; mon propos était sur la réaction de Gourmet concernant le fait qu'OSM permettait de surveiller tout le monde. C'est d'ailleurs pour ça que je n'ai fait qu'une quote que sur la partie de l'email qui me choquait. Je suis pour a 150% pour que les gens contribuent anonymement via des outils automatiques. J'ai déjà soutenu cette position plusieurs fois Émilie, Il n'était pas dans mon attention de dire que tu t'en foutais, mais que *certains* s'en foutaient, je visais plus des personnes hors de la communauté OSM dont une personne a parlé dans un précédent mail et dont la Communauté Européènne se serait émue :) Y. -- Yves Jacolin - Donner la liberté aux individus ne suffit pas, il faut aussi leur donner du pouvoir, de la puissance d'agir. M Gauchet Give freedom to people is not enough, we also have to give them the power to use this freedom, to act. M Gauchet - http://yjacolin.gloobe.org http://softlibre.gloobe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] P'tchiotte quechion sur les lieux-dits
2009/8/21 Gourmet o...@blas.net: A ma connaissance, le fond de carte de l'armée à été versé à l'IGN à sa fondation... Et ça en fait une source libre de droits ça ? Les toponymes n'appartiennent à personne (ou à tout le monde si tu préfères). C'est copier une carte qui pose problème. Mais comme une partie du travail de l'IGN est une payée par l'état, je ne saurais dire si copier les toponymes est interdit ou pas (la même question se pose par exemple pour l'altitude des sommets). L'autre question est : quel est l'intérêt de cartographier des toponymes qui ne sont plus utilisés ? La préservation ... Db Préserver ok, mais à plusieurs conditions : vérifier que le toponyme est toujours en usage. Si oui, pas de pbl. Si non, utiliser un tag particulier pour l'ancien toponyme (old_name par exemple) et réserver le tag name pour le nom actuellement en usage. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Tag] sally port ?
J'ai un doute sur la traduction actuelle du tag barrier=sally_port dans le wiki : poterne. J'ai l'impression que cela désigne aussi bien les anciennes poternes de châteaux-forts : http://www.undiscoveredscotland.co.uk/edinburgh/edinburghcastle/index.html que les portes d'entrées de forts modernes: http://www.clis.com/friends/FM%20Photo%20Tour.html Si personne n'est contre, je vais donc modifier la définition du wiki par: Désigne aussi bien les anciennes poternes que les entrées gardées de fortifications modernes. Je ne crois pas non-plus qu'on puisse utiliser ce tag pour désigner les portes de fortifications ou remparts entourant certaines villes médiévales. Ou bien ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] イギリスでの事例
Mage Whopperです。 @openstreetmapからのRTになります。 イギリスの国土交通省にあたるDFTがNaPTANというデータを追加公開しました。 日本で言う数値地図の一部に相当するもので、 イギリス全土のバス停の位置情報を含むとのことです。 具体的には イギリスにある35万のバス停、鉄道駅、トラム停車場、フェリー乗り場 の位置情報、名前、番号（？）その他の付加情報で おおざっぱにいって日本の数値地図の公共交通機関のPOIに絞ったもの のようです。 元データは権利的にフリーではなかったようですが イギリス政府はこれをCC-by-saでOpenstreetmapに提供しました。 すばらしい事例だと思いました。 個人的にはOSM側からDFTに協力を要請したのか 逆なのかにとても興味あります。 以前から協力体制があったようなので この件に関してはっきりさせるのは難しいかもしれませんが。。 国土交通省や交通関係の一般企業と データをやり取りできる（＝メリットを提供できる） ような日がくることを夢見つつお伝えせていただきます。 元のブログ記事（英語） http://blog.okfn.org/2009/08/20/where-is-the-nearest-bus-stop-uk-department-for-transport-adds-naptan-data-to-open-street-map/ DFT（英語） http://www.dft.gov.uk/ OSMのWikiにNaPTANの紹介があります。（英語） http://wiki.openstreetmap.org/wiki/NaPTAN Mage Whopper magewhop...@gmail.com ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-GB] District Boundaries - N Wales
Well I'm pleased that they agree with me, but I'm not the oracle! This is another source quoting the same general information. Do the Scottish and Northern Irish counties generally extend to the low water mark too? Drawing from the NPE maps seems to be our only reasonable source for the low water mark. Bogus Zaba wrote: I have had confirmation from the Local Government Boundary Commission for Wales who agree with the view below from Chris Hill. They say : "...in general the seaward extent of a local authority is the low water mark as defined by Ordnance Survey. The exception to this are certain islands such as Flat Holm (which comes under Cardiff), where the courts have made specific decisions, such as Milford Haven, and where the Secretary of State has made an Order extending the local authority boundary to include an area of the sea (under Section 71 of the 1972 Act). As far as I am aware no such orders have been made in respect of Welsh local authorities." That's good enough for me. I will define the low water mark from NPE and use that in the Flinthsire and Denbighshire boundaries. Bogus Zaba Chris Hill wrote: I have researched boundaries of the English counties and unitary authorities. it seems that generally they follow the mean low water mark. Some of the land is owned by the council, some by private owners but often by the Crown Estates and leased to the council. By using the low water mark the council administers the beach or foreshore and the Crown Estates administer the seabed beyond. Cheers, Chris Bogus Zaba wrote: I have completed the following relations for Unitary Authority Boundaries and put them in the Wales Wiki : Wrexham (137981), Flintshire (198566) and Denbighshire (192442). Now some inevitable questions: 1. How should Flintshire and Denbighshire be completed out at sea? On the Wales Wiki it says "The current Wales Boundary (08 July 2009) is both wrong and unhelpful." So I guess I should not be using that. Currently Unitary Authority boundary lines go out to sea traced from the NPE, but they do not join up with any coastal boundary. As it happens in this part of NE Wales, nobody seems to have made the coastline (high water mark?) ways to be members of the national boundary relation, although that has been done for about 70% of the welsh coastline. 2. In putting together the relations for these boundaries I found myself splitting a lot of roads and streams into relatively short sections so that I could then make these sections members of the boundary relation. Is this recognised good practice, or is it better to make a separate boundary way which simple shares nodes with the relevant stream or road etc ? 3. In doing all this I have used the NPE layer which can be used as a backdrop in josm and potlatch. I have realised that this NPE is not the same NPE as can be found in other places (eg the postcode collection application at http://www.npemap.org.uk/). The latter is clearer than the tiles in josm and potlatch especially regarding parish boundaries (which you find yourself tracing) which are nice dotted lines in the postcode application and faded grey lines in the josm/patlatch layers. Can the clearer (newer?) tiles be made available in the osm editing environments ? Thanks Bogus Zaba ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Coverage figures for Scotland and Wales
We've had a dicky broadband connection for the 24 hours or so, but it seems to be OK now, so I've been able to upload the detailed coverage figures for Scotland and Wales here - http://www.reedhome.org.uk/Documents/SWcoverage.csv ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
