Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: Tom Hughes skrev: In message [EMAIL PROTECTED] David Earl [EMAIL PROTECTED] wrote: Unfortunately removing the related node isn't going to work, because Mapnik won't then render parking symbols. And it is a lot of work to do that. I believe it will - as far as I know mapnik has rendered those symbols for parking areas for some time. Since we have contradictory behaviour in the two renderers we can't resolve this automatically unless osmarender can look and see on the fly if there is a P node inside the area it is trying to do one for automatically. I believe it is fundamentally wrong to add nodes which duplicate areas, although I know it is quite common. Let me just remind you all, that there are no rules. There are only recommendations. When you all come to realize that, you will find that it is not a question of whether someone has put a node within an area in the database, but a question of whether the rendering engine in question can figure out not to render the node if it has the same icon as an renderengine-placed icon for the area containing that node. The underlying problem is that the 'recommendations' keep changing. A node to allow a 'P' to appear WAS used when there was nothing to produce one otherwise. NOW that areas are ( in some cases ) being rendered and annotated the additional nodes may well be unnecessary. The real problem here is that CHANGES to the recommendations are not being followed through with recommendations to remove the original version. BUT as has been pointed out - the renderers follow their own interpretation of the recommendations, so at present one has to decide WHICH renderer you are adding data for :( *SO* perhaps there should be some RULES that at least provide some consistency in how things are being added. And perhaps in 10 years time someone may get around to considering how areas SHOULD be used? We need ONE set of rendering rules that will produce consistent results and when a rendering engine is NOT following the rules there should be a decision either to add the rule consistently, or remove it. A SWITCH for 'consistent' rendering which can be disabled on local versions were people are not bothered about consistency? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, NOW that areas are ( in some cases ) being rendered and annotated the additional nodes may well be unnecessary. not really. When passing a parking lot, I still want to be able to place a node and tag it accordingly, without the need to make it an area. The area may be added later, and then the node should be deleted. Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Christoph Eckert wrote: Hi, NOW that areas are ( in some cases ) being rendered and annotated the additional nodes may well be unnecessary. not really. When passing a parking lot, I still want to be able to place a node and tag it accordingly, without the need to make it an area. The area may be added later, and then the node should be deleted. EXACTLY my point - You are working THAT recommendation! and even with the new 'recommendation' removing the node may not be the right answer CURRENTLY! Mapnik currently will not render your parking space if you do that? Osmarender is following a different recommendation. Asking the RENDERERS to sort out the mess is wrong - even thought it is the renderers that have created the problem! *IF* the current recommendation is as you have written, then both renders need to follow it. The recommendation makes sense, but currently it is possibly only right for Osmarender :( We need RULES that are consistent and that everyone follows to produce consistent results. At present people are changing the rules as they see fit, without ensuring that everyone else is doing the same. Hence we have different information being displayed, or duplicate information. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
In message [EMAIL PROTECTED] J.D. Schmidt [EMAIL PROTECTED] wrote: Tom Hughes skrev: Since we have contradictory behaviour in the two renderers we can't resolve this automatically unless osmarender can look and see on the fly if there is a P node inside the area it is trying to do one for automatically. I believe it is fundamentally wrong to add nodes which duplicate areas, although I know it is quite common. Let me just remind you all, that there are no rules. There are only recommendations. When you all come to realize that, you will find that it is not a question of whether someone has put a node within an area in the database, but a question of whether the rendering engine in question can figure out not to render the node if it has the same icon as an renderengine-placed icon for the area containing that node. I said I believe. In other words it was my personal opinion of the best way to tag such things. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, We need RULES that are consistent and that everyone follows to produce consistent results. we have to cope with the fact that this is a volunteer project. People will always tag differently. IMO it's not a severe problem if there are a couple of parking lots which are mapped both as an area and a node. We do the same for several other areas as well, including nodes for places which are surrounded by a landuse=residential name=foo polygon. Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Christoph Eckert wrote: Hi, We need RULES that are consistent and that everyone follows to produce consistent results. we have to cope with the fact that this is a volunteer project. People will always tag differently. IMO it's not a severe problem if there are a couple of parking lots which are mapped both as an area and a node. We do the same for several other areas as well, including nodes for places which are surrounded by a landuse=residential name=foo polygon. Again - the fact that people are giving time to enter data is precisely why we need to be producing a guide to how to do things that is consistent. If people are going to tidy up these 'couple of problems' then we don't want one person deleting a node and another adding it back because they are looking at different views of the same data :( *ALSO* we also don't need people wasting time making the renderers play silly tricks to make things look right. Lets just be consistent in how things are handled. What ever the inconsistency! -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine skrev: Again - the fact that people are giving time to enter data is precisely why we need to be producing a guide to how to do things that is consistent. If people are going to tidy up these 'couple of problems' then we don't want one person deleting a node and another adding it back because they are looking at different views of the same data :( *ALSO* we also don't need people wasting time making the renderers play silly tricks to make things look right. Lets just be consistent in how things are handled. What ever the inconsistency! You need to look at it differently. From the view you are putting forth above, you seem to equalize the rendered output in the form of Mapnik and Osmarender maps to Openstreetmap. And I can see why, since those two items produce the currently most visible part of OSM. BUT remember, the DB is one thing, the rendering of data from the db is another thing altogether. Look at the db as a big sea of data, where it is your (the rendering engine) task to harvest the data that you want to render. Not to impose rules and limitations on what form the data in the DB is entered in. IMHO one of the reasons why OSM has gained such notoriety and following among neogeographers, established carthographers, and joe-public alike, is the fact that it is not a mapproducing framework bound by strict and defined ISO-like rules, but a framework that is more akin to social networking for the map-inflicted. If the two rendering engines used currently differ in the way they render said data, then its the rendering rules used in those engines that need to be put into sync. Its not done by imposing limitations or strict rules on what can/should be put into the DB. If one person observed a parking lot, but didn't have time to log the boundaries of the lot, and just placed a node with the corresponding tag, then later another person comes along and logs the boundary of the parking lot, and puts an area out of that data into the DB, he shouldn't delete the node another person made. Maybe that person is using the data from the DB to keep a POI record of parking lots. He might be the only one doing so, but thats still one of the forces of the OSM project - Log it, tag it, put it into the DB - even if you are the only person ever going to use that data. So IMHO it's up to the rendering engines to render the data smartly. It's not the rendering engines that decide what should be put into the DB. Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 24/02/2008 10:53, J.D. Schmidt wrote: So IMHO it's up to the rendering engines to render the data smartly. It's not the rendering engines that decide what should be put into the DB. I'm on both sides here: I agree that it would be better not to have both a node and an area; OTOH, there's already lots and lots of these, so it is shooting ourselves in the foot not to clear up the mess in one way or another. And I'm confused about what Mapnik is actually doing to get this right (if indeed it is always getting it right). There's two ways to do it: either (1) we pass over the data (ideally automatically) and check for parking node within parking polygon, delete the node (or maybe just change its tag, to say parking:redundant, so we don't lose anything accidentally), and transfer any name tag to the area, providing there is no clash,. i.e. the area doesn't already have a (different) name or (2) we change osmrender so it only puts the icon in when there isn't already a relevant node. This would require osmarender to (a) maintain some state: keep a list of parking nodes or areas, and (b) to do the artificial icon after all the nodes (in the layer presumably). Can XSLT do this? In both cases, I think a bounding box test would be sufficient rather than a general point in polygon test, but that's a pretty minor detail. (2) has the advantage that the mapper can override a naive rendering algorithm, and copes with the existing data, but I suspect not knowing much about XSLT that this would be rather hard to do, but it does mean the existing bad practice (in quotes because not everyone is of that opinion) is propagated. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, If one person observed a parking lot, but didn't have time to log the boundaries of the lot, and just placed a node with the corresponding tag, then later another person comes along and logs the boundary of the parking lot, and puts an area out of that data into the DB, he shouldn't delete the node another person made. I'm not sure. Currently I would delete it. Not to please the renderers, but as I see it as redundant data. Maybe that person is using the data from the DB to keep a POI record of parking lots. I do POIs and my tool currently only can do nodes. If parking lots are replaced by areas, I need to fix my tool. He might be the only one doing so, but thats still one of the forces of the OSM project - Log it, tag it, put it into the DB - even if you are the only person ever going to use that data. OSM is wiki style. If someone comes along and refines an area, it may simply happen that the node disappears as soon the area is created. I agree that anyone can put data into the db, but it's not there for eternity but to be modified. And modification also means deletion. So IMHO it's up to the rendering engines to render the data smartly. It's not the rendering engines that decide what should be put into the DB. Seconded. Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: Lester Caine skrev: Again - the fact that people are giving time to enter data is precisely why we need to be producing a guide to how to do things that is consistent. If people are going to tidy up these 'couple of problems' then we don't want one person deleting a node and another adding it back because they are looking at different views of the same data :( *ALSO* we also don't need people wasting time making the renderers play silly tricks to make things look right. Lets just be consistent in how things are handled. What ever the inconsistency! You need to look at it differently. From the view you are putting forth above, you seem to equalize the rendered output in the form of Mapnik and Osmarender maps to Openstreetmap. And I can see why, since those two items produce the currently most visible part of OSM. BUT remember, the DB is one thing, the rendering of data from the db is another thing altogether. Look at the db as a big sea of data, where it is your (the rendering engine) task to harvest the data that you want to render. Not to impose rules and limitations on what form the data in the DB is entered in. IMHO one of the reasons why OSM has gained such notoriety and following among neogeographers, established carthographers, and joe-public alike, is the fact that it is not a mapproducing framework bound by strict and defined ISO-like rules, but a framework that is more akin to social networking for the map-inflicted. If the two rendering engines used currently differ in the way they render said data, then its the rendering rules used in those engines that need to be put into sync. Its not done by imposing limitations or strict rules on what can/should be put into the DB. THAT is all I am saying. EXCEPT that tagging should be consistent, something which does not happen currently. If one person observed a parking lot, but didn't have time to log the boundaries of the lot, and just placed a node with the corresponding tag, then later another person comes along and logs the boundary of the parking lot, and puts an area out of that data into the DB, he shouldn't delete the node another person made. Maybe that person is using the data from the DB to keep a POI record of parking lots. He might be the only one doing so, but thats still one of the forces of the OSM project - Log it, tag it, put it into the DB - even if you are the only person ever going to use that data. We will have to differ there. Although I suspect that we are actually saying the same thing - just differently. There is a lot of tagging that is not rendered. That is fine, and while it would be nice to be consistent, deleting it is a matter of agreement. *IF* the tagging is being done properly, then both parking:area and parking:node should produce the same basic set of tags, so that upgrading a parking:node to a parking:area would retain all of the core information. If we are going to maintain two different sets of parking data nodes and areas then BOTH should be supplied. So IMHO it's up to the rendering engines to render the data smartly. It's not the rendering engines that decide what should be put into the DB. I see a major processing hit if every time you find an area you then have to process every node inside that area to see if it is ( whether parking, place or any other node/area conflict ) a duplicate of the area data. You then also have to decide if the node or area data takes priority? If one says private and the other public which should take priority. *I* am looking at the data here, and the problems I have with making the same decisions when two conflicting sets of tag information arises! -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Christoph Eckert wrote: Maybe that person is using the data from the DB to keep a POI record of parking lots. I do POIs and my tool currently only can do nodes. If parking lots are replaced by areas, I need to fix my tool. This is the point I am at as well! We need to be consistent in the way POI's, what ever they are, are identified, and a node is currently easier to tabulate than an area. So perhaps we REQUIRE a node attached to every area which has the tag information. Ignoring the rendering inconsistencies and just looking at the raw data, how do we produce a list of 'parking lots' or any other area/node defined data. In order to fix POI type tools we end up having to process graphical data when a simple set of rules could remove the problem? I keep coming back to the is_in problem and this is just another example of it. WHEN an area is created and the original node is_in it then an automatic is_in with a unique identifier could be created which flags that there is an area that superceds the node. We can then simply read the data and when we find nodes with area is_in tags we can simply ignore them if appropriate leaving just the area POI tags. PERSONALLY I would like to be able to process the raw data without having to ALSO carry out complex area checks every time I find an 'area'. If we need to maintain matching nodes to go with that area, then there should be some flagging to at least indicate that there is an alternative. David's 'parking:redundant' could better be tagged 'parking:see_area' although I will keep hammering the simple concept of a unique is_in identifier so we get 'parking:is_in:element_id'. A concept that will tidy ALL of the area/data information tree. I know this is not liked by the XML purists, but being able to jump directly to related data will always speed up data mapping? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
In message [EMAIL PROTECTED] David Earl [EMAIL PROTECTED] wrote: On 24/02/2008 10:53, J.D. Schmidt wrote: So IMHO it's up to the rendering engines to render the data smartly. It's not the rendering engines that decide what should be put into the DB. I'm on both sides here: I agree that it would be better not to have both a node and an area; OTOH, there's already lots and lots of these, so it is shooting ourselves in the foot not to clear up the mess in one way or another. And I'm confused about what Mapnik is actually doing to get this right (if indeed it is always getting it right). Well mapnik actually fakes up nodes during the import into postgis in this case, so I guess it is doing something clever to avoid faking up the node if one already exists - it may well be doing a bbox query against postgis to see if there is already a node within the area. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Richard Fairhurst wrote: Lester Caine wrote: We need ONE set of rendering rules that will produce consistent results No we don't - that's half the point of OSM. If we had ONE set of rendering RULES then we wouldn't have a CYCLE map. I'm not talking about STYLE - I'm talking base data! ANY map can display what it wants, how it wants, but they will all have the same problem where there are conflicts between area and node data. NOTHING precludes rendering what ever we want, but how does the cycle map solve this conflict? Just ignore 'parking' and this particular problem goes away, but if someone decides parking needs to be on the cycle map which area/node data should it work with? Do you have to re-write the renderer every time someone comes up with a new conflict? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine skrev: Do you have to re-write the renderer every time someone comes up with a new conflict? Short answer : Yes. Long answer : The renderer operates on a subset of the data contained in the DB. It is up to the operator of the renderer to extract and possibly massage that data into a format that the renderer can utilize. It is not the place of the renderer to impose limitiations or rules into what is in the DB, since the the DB is/might/will be used for other tasks than just rendering maps. This is similar to the previous discussion this month, where someone wanted to impose limitations on what charactersets could be used for tagnames. All together now, repeat this months mantra after me : Implementing non-DB technical limitations and rules for content in the DB is bad, recommendations and smarter algorithms in renderers are good. Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: Lester Caine skrev: Do you have to re-write the renderer every time someone comes up with a new conflict? Short answer : Yes. Long answer : The renderer operates on a subset of the data contained in the DB. It is up to the operator of the renderer to extract and possibly massage that data into a format that the renderer can utilize. It is not the place of the renderer to impose limitiations or rules into what is in the DB, since the the DB is/might/will be used for other tasks than just rendering maps. This is similar to the previous discussion this month, where someone wanted to impose limitations on what charactersets could be used for tagnames. Should never have been discussed - Unicode has to be used even if there is an arbitrary limit of English tag names - the content has to be unicode and mixing that with anything else is simply crass. All together now, repeat this months mantra after me : Implementing non-DB technical limitations and rules for content in the DB is bad, recommendations and smarter algorithms in renderers are good. Bullshit. TAGGING as laid out in the wiki are all rules for content but as yet they do not provide a consistent USABLE base once one moves away from the basic road stuff. And even the base road stuff people are trying to change the rules! See my other message about the area/node conflict. This problem arises everywhere that node and area options exist for a tag and there needs to be AGREEMENT on how the conflict is handled. Some people using different methods of handling it for different tags is no use to anybody so lets decide ONE way of handling the conflict and stick to it. Personally I have no particular feeling anyway, but a logical means if identifying a SINGLE list of parking places ( for example - but any node/area rag! ) is just common sense. This is just a simple case of how do you identify a set of tags UNLESS there is agreement about how a tag is used. *IF* we are going to allow both node and area tags for the same item then we need to ensure that they ARE returning the same data but some logical method of ensuring that the node and area returns a CONSISTENT set of answers is essential otherwise we have anarchy. LOGICALLY - there should never have been a problem created. A POI element should consist of a single entity which may have additional area information. Even those tags that are currently only defined as 'node' in many cases WILL be expanded to include area information at some point. So PLEASE can we have some sensible method of identifying PAIRS of tags so we can THEN decide what to do with them !!! -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On Sun, 2008-02-24 at 12:19 +, Tom Hughes wrote: In message [EMAIL PROTECTED] David Earl [EMAIL PROTECTED] wrote: On 24/02/2008 10:53, J.D. Schmidt wrote: So IMHO it's up to the rendering engines to render the data smartly. It's not the rendering engines that decide what should be put into the DB. I'm on both sides here: I agree that it would be better not to have both a node and an area; OTOH, there's already lots and lots of these, so it is shooting ourselves in the foot not to clear up the mess in one way or another. And I'm confused about what Mapnik is actually doing to get this right (if indeed it is always getting it right). Well mapnik actually fakes up nodes during the import into postgis in this case, so I guess it is doing something clever to avoid faking up the node if one already exists - it may well be doing a bbox query against postgis to see if there is already a node within the area. Right now it does not do this. As I think Richard mentioned before, the reason you generally do not see the second node is that the rendering collision detection algorithm removes one of the icons. If you go to say zoom 18 then you might see 2 icons, but only on large car parks where the node is not near the centre of the area. I can not find any examples myself. I've been tempted to add the intelligent algorithm you describe into osm2pgsql for a while now but it has yet to reach the top of my todo list. Unfortunately we don't build the spatial indexes on the data until the import is complete so we might have to delay this duplicate detection until the end of the processing (or maybe the points table is small enough to be scanned sequentially without too much of a hit). Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine skrev: J.D. Schmidt wrote: Lester Caine skrev: Do you have to re-write the renderer every time someone comes up with a new conflict? Short answer : Yes. Long answer : The renderer operates on a subset of the data contained in the DB. It is up to the operator of the renderer to extract and possibly massage that data into a format that the renderer can utilize. It is not the place of the renderer to impose limitiations or rules into what is in the DB, since the the DB is/might/will be used for other tasks than just rendering maps. This is similar to the previous discussion this month, where someone wanted to impose limitations on what charactersets could be used for tagnames. Should never have been discussed - Unicode has to be used even if there is an arbitrary limit of English tag names - the content has to be unicode and mixing that with anything else is simply crass. All together now, repeat this months mantra after me : Implementing non-DB technical limitations and rules for content in the DB is bad, recommendations and smarter algorithms in renderers are good. Bullshit. TAGGING as laid out in the wiki are all rules for content but as yet they do not provide a consistent USABLE base once one moves away from the basic road stuff. And even the base road stuff people are trying to change the rules! Correction: Tagging as laid out in the wiki is NOT rules for content IN THE DB. Let me just repeat that: Tagging as laid out on the wiki in the Mapfeatures page is NOT rules governing the content in the DB. They are recommendations, to be used if you'd like to see your content rendered by the current default rendering engines used on the OSM site. Nothing more, nothing less. See my other message about the area/node conflict. This problem arises everywhere that node and area options exist for a tag and there needs to be AGREEMENT on how the conflict is handled. Some people using different methods of handling it for different tags is no use to anybody so lets decide ONE way of handling the conflict and stick to it. Personally I have no particular feeling anyway, but a logical means if identifying a SINGLE list of parking places ( for example - but any node/area rag! ) is just common sense. This is just a simple case of how do you identify a set of tags UNLESS there is agreement about how a tag is used. *IF* we are going to allow both node and area tags for the same item then we need to ensure that they ARE returning the same data but some logical method of ensuring that the node and area returns a CONSISTENT set of answers is essential otherwise we have anarchy. There is NO agreement on tags used, and should NOT be any such agreement on tags used, since the DB is more akin to a wiki - if you can describe it within the framework of k=name v=value/ then it can go into the DB for storage. There IS an agreement on RECOMMENDATIONS of tags to be used IN THE SCOPE of rendering maps with the default rendering engines currently used by OSM. Its then up to the rendering engines to visualize those tags according to whatever rules they use in their visualization attempts. LOGICALLY - there should never have been a problem created. A POI element should consist of a single entity which may have additional area information. Even those tags that are currently only defined as 'node' in many cases WILL be expanded to include area information at some point. So PLEASE can we have some sensible method of identifying PAIRS of tags so we can THEN decide what to do with them !!! It's still not a OSM DB problem. It's a problem to be solved by the rendering engines. Imposing non-DB technical limitations and rules to the data put into the DB, in order to please the rendering mechanism is fundamentally wrong. Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On Sun, Feb 24, 2008 at 12:35 PM, Lester Caine [EMAIL PROTECTED] wrote: Richard Fairhurst wrote: Lester Caine wrote: We need ONE set of rendering rules that will produce consistent results No we don't - that's half the point of OSM. If we had ONE set of rendering RULES then we wouldn't have a CYCLE map. I'm not talking about STYLE - I'm talking base data! ANY map can display what it wants, how it wants, but they will all have the same problem where there are conflicts between area and node data. NOTHING precludes rendering what ever we want, but how does the cycle map solve this conflict? However I see fit. It's my map, and I can quite literally do whatever I want. I take the data from the database, do some magic, and out comes a map. If I choose to do things differently than whatever osmarender or the main mapnik map does, then so bit it. I might render just parking areas. I might put in some nodes. I might do both, or do neither. Now I say this as an illustration of what each renderer does - they make their own decisions as to what to do. I don't even understand why you want consistency in the outputs - the main osmarender and mapnik layers are different, and much of it just comes down to cartographic style. As to the specifics of how mapnik works, see osm2pgsql's add_parking_node() at http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/output-pgsql.c#L362 for the code to auto-add a parking node. On the main map it has parking as non-overlapping as per http://trac.openstreetmap.org/browser/applications/rendering/mapnik/osm.xml#L154 so the duplicate icon issue is solved by this overlap avoidance. And if you think this is particularly onerous for the renderers to deal with, then you're probably unaware of how much other stuff needs to be taken care of too! Cheers, Andy Just ignore 'parking' and this particular problem goes away, but if someone decides parking needs to be on the cycle map which area/node data should it work with? Do you have to re-write the renderer every time someone comes up with a new conflict? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Pint symbols: YUCK!
The old pint symbols look amateurish, the new ones only hideous. Just take a look at http://informationfreeway.org/?lat=61.4978902211692lon=23.764454385823434zoom=16layers=F0B0F -- Lauri Hahne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
Lauri Hahne skrev: The old pint symbols look amateurish, the new ones only hideous. Just take a look at http://informationfreeway.org/?lat=61.4978902211692lon=23.764454385823434zoom=16layers=F0B0F Thats how the pint glasses look, at the end of an evening drinking with brits.. Kinda' blurry and out of focus. Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Camera and Dictaphone clocks
I mentioned in the thread about continuous audio mapping yesterday that the audio was appearing to drift away from the corresponding waymarks after a while. I have now determined that this is due to the inaccuracy of the clock in my dictaphone. I have implemented a solution for audio in JOSM - see below - but this has implications for using camera images as well. I recorded three hours off the radio this morning to include the pips at 9am and noon (for non Britishers: Greenwich time signal, an accurate clock which is broadcast on the hour most hours on BBC Radio 4). A suitable alternative would be to track the (very accurate) GPS clock, but that would have meant going outside. I then measured the length of the recording between the start of each of the long pips in Audacity, whose timer is derived from the audio sampling rate and therefore reflects the clock in the dictaphone. Sure enough it came out at a remarkably inaccurate 3h00m17s (0.157% out): that means that my dictaphone loses about 2 minutes day! I would not be at all surprised to find that camera clocks are also similarly inaccurate - they probably use the same silicon! A similar test for a camera is obviously to photograph a GPS display several hours apart and compare the time difference the image time stamp says with the GPS time difference shown. The consequence is that synchronising the time by saying NOW or photographing the GPS clock is _not_ sufficient. If you're using voice or pictures just to annotate waypoints, it's just a minor inconvenience - the picture or sound isn't quite where you thought it would be on the track, but the waypoint is from the GPS, so accurate. But if you're using the synchronised timestamp or offset into a recording to imply a feature's location, you could be 50m or more out after two-hours of a bicycle mapping session (10s error @ 5m/s). For the new audio facilities in JOSM, I've added a voice recorder calibration box into the Audio Preferences panel (will be in tomorrow's build). You measure the purported length of a long chunk of audio to the true time, and enter the ratio, so in my case this is 1.00157. You could do this specially as I did, or during a mapping session just by putting sync cues at either end of your recording. You can measure it either in Audacity or similar as I did, or in JOSM itself by inserting audio markers at the geographical location of the sync cues and noting the time time difference of labels (dG), sync at the first mark, and then time the difference between the second mark and the second audio cue in the commentary (dA). The calibration is then (dA+dG)/dG. Of course if your device clock runs fast, you might have to go back a few seconds, and your ration would be a bit less than 1. Of course, this assumes that the clock runs at a constant, if incorrect, rate both during a session, and, if you don't recalibrate each time then between sessions as well. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
On 24/02/2008, J.D. Schmidt [EMAIL PROTECTED] wrote: Lauri Hahne skrev: The old pint symbols look amateurish, the new ones only hideous. Just take a look at http://informationfreeway.org/?lat=61.4978902211692lon=23.764454385823434zoom=16layers=F0B0F Thats how the pint glasses look, at the end of an evening drinking with brits.. Kinda' blurry and out of focus. That must be due to drinking warm beer. -- Lauri Hahne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On Sun, 2008-02-24 at 09:28 +0100, Christoph Eckert wrote: not really. When passing a parking lot, I still want to be able to place a node and tag it accordingly, without the need to make it an area. The area may be added later, and then the node should be deleted. This is also my opinion on the matter (not that it counts). -- Bruce Cowan [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
On Sun, 2008-02-24 at 16:46 +0200, Lauri Hahne wrote: The old pint symbols look amateurish, the new ones only hideous. Just take a look at http://informationfreeway.org/?lat=61.4978902211692lon=23.764454385823434zoom=16layers=F0B0F That looks like a few streets with lots of bars. I don't see anything wrong with it. What do you want it to look like? A different symbol? Not to show the pub symbol? Show more of other symbols? Buildings outlines being shown? Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt schrieb: TAGGING as laid out in the wiki are all rules for content but as yet they do not provide a consistent USABLE base once one moves away from the basic road stuff. And even the base road stuff people are trying to change the rules! Correction: Tagging as laid out in the wiki is NOT rules for content IN THE DB. Let me just repeat that: Tagging as laid out on the wiki in the Mapfeatures page is NOT rules governing the content in the DB. They are recommendations, to be used if you'd like to see your content rendered by the current default rendering engines used on the OSM site. Nothing more, nothing less. True. I don't understand why it's so fashionable on this list to play down the importance of Map features. Without that page all those 80GB of cryptic XML would be pretty useless. But that's nothing bad or something we should encounter, that just the nature of any map, whether it's stored in a DB or printed on colorful paper. A map is an abstract description of the landscape, that's what makes it different from an aerial or plat. Someone making that description uses certain symbols or certain code for certain features. Someone who uses that description needs to know what every symbol/code resembles. On a paper map that's done by the map keys which tell you whether those blue lines are motorways, railways or maybe rivers, for OSM-data Map features tell you. Anybody can enter anything into the DB, we can't change that, we don't want to change that and we are all aware of that. But when I (and most other mappers as well) enter something in the DB I want other people to know what it stands for in reality. I could use some crude tags only I know, but what's then the point in making it accessible for the whole world. And things like the cycle map would definitely not exist without some kind of explanation of the relevant tage in the wiki. Without this translation/documentation (ncn=xyz means this way is part of a route that...) there wouldn't be all those tags in the DB. I'm sure Andy didn't think, well today I'm gonna render abc=xyz, maybe there are some mappers who describe their cycleroutes just that way. Without Map features OSM is like an undocumented command-line programm: To be certain about all it's capabilities you'd need to read every single line of code. And reading planet.osm might take a while... regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
IMHO The symbol is ugly. Even the old one looked better than the current one. On 24/02/2008, Jon Burgess [EMAIL PROTECTED] wrote: On Sun, 2008-02-24 at 16:46 +0200, Lauri Hahne wrote: The old pint symbols look amateurish, the new ones only hideous. Just take a look at http://informationfreeway.org/?lat=61.4978902211692lon=23.764454385823434zoom=16layers=F0B0F That looks like a few streets with lots of bars. I don't see anything wrong with it. What do you want it to look like? A different symbol? Not to show the pub symbol? Show more of other symbols? Buildings outlines being shown? Jon -- Lauri Hahne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Andy Allan wrote: Now I say this as an illustration of what each renderer does - they make their own decisions as to what to do. I don't even understand why you want consistency in the outputs - the main osmarender and mapnik layers are different, and much of it just comes down to cartographic style. And there is nothing to distinguish between duplicate items contained in the underlying data. RENDERING is not the only use for the data but the problem of duplicate icons highlights the underlying problem - AND IT IS A PROBLEM !!! As to the specifics of how mapnik works, see osm2pgsql's add_parking_node() at http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/output-pgsql.c#L362 for the code to auto-add a parking node. On the main map it has parking as non-overlapping as per http://trac.openstreetmap.org/browser/applications/rendering/mapnik/osm.xml#L154 so the duplicate icon issue is solved by this overlap avoidance. BUT that only works for 'parking' - add every other node/area duplicate problem! Add situations where there is no overlap avoidance such as actually processing the data someone is going to code each case individually? And if you think this is particularly onerous for the renderers to deal with, then you're probably unaware of how much other stuff needs to be taken care of too! I KNOW the problem of dealing with the CURRENT data - in many cases it is unusable for anything OTHER than rendering and needs the sort of bodge being discussed to sort out the mess. Some people not be bothered by that problem, because they only want a simple map output, but 90% of the tagging information will allow us to search for WHICH area of the map to display. Having in essence to 'render' areas to find out if nodes are contained in them and then guess if a node IS a duplicate is not practical as the size of the DATA grows. I'm looking at some 50 other tags that may have node/area duplicates - personally how they are rendered does not bother me at all - I want to be able to navigate the data and produce CONSISTENT search results - which are then used to DISPLAY the correct area of a map or simply offer alternatives to select from. A very simple fix for this problem is to display everything on the basis that the node IS different to the area. The renderers can worry about icons on top of one another - be they duplicate parking icons or school, public building or whatever. We then TIDY things up by the convention that there is only one entry for a tagged POI and if an existing node is upgraded to an area, then the node information becomes part of the area tags, and the node is deleted. No need for reams of processing and new bodge code for every node/area tag conflict? We then don't have to worry about duplicates - they don't exist. If they do, then one or other needs to be merged to leave a single distinct entry? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
Lauri Hahne wrote: IMHO The symbol is ugly. Even the old one looked better than the current one. In humble opinion we shouldn't judge other people's effort so harshly unless we are prepared to draw the pint icon by ourselves ;) Igor -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] New in JOSM: Paste Tags
I have added a new operation on the JOSM Edit menu: Paste Tags (CTRL+SHIFT+V). This will be in tomorrow's build. This applies to the current selection the tags of the items previously copied to the paste buffer with Edit Copy. Only tags for items of like types are assigned, so selected nodes will take on tags of nodes in the paste buffer, selected ways of copied ways and selected relations of copied relations. (When you Copy a way, its nodes are also copied - or you wouldn't be able to Paste it - so if any nodes are selected for Paste Tags, the tags of the original way's nodes will be applied to the selected nodes). Paste Tags will overwrite tags with the same key in the target selection, but you can't Paste Tags if there is ambiguity in what you would paste (e.g. you have copied two ways with different names). created_by is always ignored. Tags already applied to the target objects are unaffected except when they have the same keys as the source objects. Note also that Edit Copy makes a deep copy of the items, so changing the tags of the source of a previously copied item will not change what tags are pasted (or indeed what objects are pasted with Edit Paste) David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Camera and Dictaphone clocks
On 24/02/2008, David Earl [EMAIL PROTECTED] wrote: I mentioned in the thread about continuous audio mapping yesterday that the audio was appearing to drift away from the corresponding waymarks after a while. I have now determined that this is due to the inaccuracy of the clock in my dictaphone. I have implemented a solution for audio in JOSM - see below - but this has implications for using camera images as well. I recorded three hours off the radio this morning to include the pips at 9am and noon (for non Britishers: Greenwich time signal, an accurate clock which is broadcast on the hour most hours on BBC Radio 4). A suitable alternative would be to track the (very accurate) GPS clock, but that would have meant going outside. I then measured the length of the recording between the start of each of the long pips in Audacity, whose timer is derived from the audio sampling rate and therefore reflects the clock in the dictaphone. Sure enough it came out at a remarkably inaccurate 3h00m17s (0.157% out): that means that my dictaphone loses about 2 minutes day! I would not be at all surprised to find that camera clocks are also similarly inaccurate - they probably use the same silicon! A similar test for a camera is obviously to photograph a GPS display several hours apart and compare the time difference the image time stamp says with the GPS time difference shown. The consequence is that synchronising the time by saying NOW or photographing the GPS clock is _not_ sufficient. If you're using voice or pictures just to annotate waypoints, it's just a minor inconvenience - the picture or sound isn't quite where you thought it would be on the track, but the waypoint is from the GPS, so accurate. But if you're using the synchronised timestamp or offset into a recording to imply a feature's location, you could be 50m or more out after two-hours of a bicycle mapping session (10s error @ 5m/s). For the new audio facilities in JOSM, I've added a voice recorder calibration box into the Audio Preferences panel (will be in tomorrow's build). You measure the purported length of a long chunk of audio to the true time, and enter the ratio, so in my case this is 1.00157. You could do this specially as I did, or during a mapping session just by putting sync cues at either end of your recording. You can measure it either in Audacity or similar as I did, or in JOSM itself by inserting audio markers at the geographical location of the sync cues and noting the time time difference of labels (dG), sync at the first mark, and then time the difference between the second mark and the second audio cue in the commentary (dA). The calibration is then (dA+dG)/dG. Of course if your device clock runs fast, you might have to go back a few seconds, and your ration would be a bit less than 1. Of course, this assumes that the clock runs at a constant, if incorrect, rate both during a session, and, if you don't recalibrate each time then between sessions as well. My canon Ixus 55 before I broke it was spot on during a session and drifted about a second a day otherwise. I'm now back using my old Olympus 2.2megapixel monster and that I find looses about 5 seconds every 30 mins of mapping but none (well effectively none) between sessions. It seems therefore that some action of the camera, perhaps during writes to the card or something does affect the clock and I have to manually sinc to the track several times for a long mapping session. Cheers Andy -- Andy Robinson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
On 24/02/2008, Igor Brejc [EMAIL PROTECTED] wrote: Lauri Hahne wrote: IMHO The symbol is ugly. Even the old one looked better than the current one. In humble opinion we shouldn't judge other people's effort so harshly unless we are prepared to draw the pint icon by ourselves ;) Well, there can't be progress without feedback. -- Lauri Hahne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
On Sun, Feb 24, 2008 at 5:52 PM, Lauri Hahne [EMAIL PROTECTED] wrote: On 24/02/2008, Igor Brejc [EMAIL PROTECTED] wrote: Lauri Hahne wrote: IMHO The symbol is ugly. Even the old one looked better than the current one. In humble opinion we shouldn't judge other people's effort so harshly unless we are prepared to draw the pint icon by ourselves ;) Well, there can't be progress without feedback. There can't be progress without someone who can draw a decent pint glass drawing a decent pint glass. I don't think feedback that you don't like the new pint glass actually helps much, especially as the new one definitely does not look worse than the old one, even if it wouldn't win any design awards. What we're looking for is constructive feedback. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
On 24/02/2008, Dave Stubbs [EMAIL PROTECTED] wrote: There can't be progress without someone who can draw a decent pint glass drawing a decent pint glass. I don't think feedback that you don't like the new pint glass actually helps much, especially as the new one definitely does not look worse than the old one, even if it wouldn't win any design awards. What we're looking for is constructive feedback. Make it less tall and darker colours. ;) -- Lauri Hahne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
Lauri Hahne wrote: Make it less tall and darker colours. ;) Now you're being drinks-ist. I like the current one, it looks like it might contain a real drink (cider, purely for example) rather than any of this beer rubbish. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Sven Grüner skrev: J.D. Schmidt schrieb: TAGGING as laid out in the wiki are all rules for content but as yet they do not provide a consistent USABLE base once one moves away from the basic road stuff. And even the base road stuff people are trying to change the rules! Correction: Tagging as laid out in the wiki is NOT rules for content IN THE DB. Let me just repeat that: Tagging as laid out on the wiki in the Mapfeatures page is NOT rules governing the content in the DB. They are recommendations, to be used if you'd like to see your content rendered by the current default rendering engines used on the OSM site. Nothing more, nothing less. True. I don't understand why it's so fashionable on this list to play down the importance of Map features. Without that page all those 80GB of cryptic XML would be pretty useless. Thats again because you look at the DB and the usage of the data contained therein as one entity that defines OSM. If you on the other hand look at the DB and the data contained therein as one entity and the USAGE of the data in the DB as a seperate entity, you get a more correct view of the state of our wonderfull hutsputz of geodata and geodata usage. But that's nothing bad or something we should encounter, that just the nature of any map, whether it's stored in a DB or printed on colorful paper. We (OSM) do not store a map in a DB. We store geodata. A map is an abstract description of the landscape, that's what makes it different from an aerial or plat. Someone making that description uses certain symbols or certain code for certain features. Someone who uses that description needs to know what every symbol/code resembles. On a paper map that's done by the map keys which tell you whether those blue lines are motorways, railways or maybe rivers, for OSM-data Map features tell you. Anybody can enter anything into the DB, we can't change that, we don't want to change that and we are all aware of that. But when I (and most other mappers as well) enter something in the DB I want other people to know what it stands for in reality. I could use some crude tags only I know, but what's then the point in making it accessible for the whole world. Again, look at the visualization of the data as a seperate entity - related to, and an important part of OSM, but not the defining measure of OSM. An example (graphic to fit my reputation ofcourse.. You have been duly warned ;) ) : If I decided to map all the trees I have taking a leak up at on the way home from drinking bouts the last couple of years, I can do so. I'll just tag it with k=urinated_tree_were_the_leaves_has_become_yellow_brownish_in_colour v=200 ml used and processed beer/. I could even tag the same tree multiple times, depending on whether I took the piss at the north, east, west, or south side of the tree. And I could even use a different tagname such as k=Urinerede_Træer_som_har_blade_med_gul_brunlig_kulør v=200 ml brugt øl without any problems. This points out the wiki-like outlook on our DB. The tag and data has only mildly interest for anybody else, but it might have real value for me. I could be the type that tends to loose my keys everytime I take a leak in toxicated condition, and now I have the possibilty to see where I have been, and go look for them. Or maybe I'm making a map showing which trees not to sit under during summer. Whatever the reason, it's geodata, and valid to go into the DB or the 80GB of cryptic XML as you called it. It might be useless for anybody else, but it wouldn't be to me. AND it could become usefull for someone else later on (urologists researching maximum distance intoxicated people can go between leaks, city planners looking for information on best placement of public restrooms, etc, etc). The other entity - visualization of the data in the OSM DB, takes a subset of the data in the DB, and masssages it into a format that the rendering mechanism can utilize. I.E. Mapnik imports the OSM data into a postgres DB according to the rules it needs, and then renders the imported data from that mapnik specific DB. Osmarender downloads the data and post-process it into SVG compliant XML according to the rules it needs, then renders it via Batik/Inkscape. Kosmos and all the other rendering mechanisms utilizing OSM data at the moment, does similar things with the extracted OSM data for the areas the user wants visualized - extract an area from the DB, massage it (postprocess, import to own formatted DB, etc, etc), then visualize it from the postprocessed data. So as I said before, its not the rendering mechanism that should define what goes into the OSM DB. At the most basic level, if it is geodata, and can be described within the scope of k=name v=value it IS valid for inclusion in the OSM database, no matter how useless it would appear to other users. And things like the cycle map would definitely not exist without some
Re: [OSM-talk] Pint symbols: YUCK!
On Sun, Feb 24, 2008 at 7:29 PM, Richard Fairhurst [EMAIL PROTECTED] wrote: Lauri Hahne wrote: Make it less tall and darker colours. ;) Now you're being drinks-ist. I like the current one, it looks like it might contain a real drink (cider, purely for example) rather than any of this beer rubbish. Perhaps. The one on the cycle map however represents a nice tall refreshing glass of chilled lager. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Continuous audio in JOSM on tracks without waypoints
David I gave it a try today. The results were excellent. I have some feedback: 1) I found synchronising to be a bit tricky the first time you do it. This wasn't helped by the fact that I had 20 minutes of tracks before I started the audio recorder. I've updated the wiki with what I hope are clearer and better instructions. 2) While audio is playing, when I clicked on an audio marker it caused JOSM to hang. 3) The Open dialog for audio files does not appear to remember the last place that was used. Other open dialogs in JOSM do. 4) It would be nice to have keyboard shortcuts for Forward and Backwards. 5) It would be nice to hide the audio markers without also hiding the orange cursor. I don't use waypoints and found that using the orange cursor and the forward and backward buttons was all that I needed most of the time. 6) Lastly, it would be really nice if it was possible to play the audio at varying speeds. For long roads if I've made occasionals marks I don't really want to listen to the whole recording in real time, but there's not really any way of knowing where the next one will be without listening to the whole recording. Variable play speed would help with this. Overall I really like it :) 80n On Sat, Feb 23, 2008 at 10:29 PM, David Earl [EMAIL PROTECTED] wrote: Having done a two-hour long audio recording today, I find that waypoints near the end have drifted a bit. It was about 8 seconds out after about 100 minutes. I did find one problem whereby the audio player wasn't jumping ahead as far as I thought it was when you pressed the marker, which I have released a change for. But that doesn't fix the problem. I need to look into this a bit further, and there may well be a timing bug still in there somewhere, but I am also wondering whether the clock on my dictaphone is not all that accurate. I'd be interested to know whether anyone else sees discrepancies, but I suggest getting tonight's build to try it in. In the meantime, be warned, and be prepared to put a synchronisation point in say every half hour or so. (You can synchronise at more than one place along a track - you might have paused the recording, for example). David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Hughes wrote: | In message [EMAIL PROTECTED] | David Earl [EMAIL PROTECTED] wrote: | | Unfortunately removing the related node isn't going to work, because | Mapnik won't then render parking symbols. And it is a lot of work to do | that. | | I believe it will - as far as I know mapnik has rendered those | symbols for parking areas for some time. | | Since we have contradictory behaviour in the two renderers we can't | resolve this automatically unless osmarender can look and see on the fly | if there is a P node inside the area it is trying to do one for | automatically. | | I believe it is fundamentally wrong to add nodes which duplicate | areas, although I know it is quite common. I agree with this wholeheartedly. 1 item on the ground should be 1 item in the database. What no one else has suggested is that if you really need to put something in the DB twice, then at least use a relationship to link the DB objects together. I expect that someone with PostGIS knowledge can construct a query to quickly identify all the parking nodes inside parking areas and produce a list. I'm sure that many of us could write a perl or python script to take this list and delete or relate the nodes. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHwfo4z+aYVHdncI0RAiLwAKDknPqP+m3PP6okGzOsJl8r4g5LnwCg+iZv CZ/eiOlZbSRqpDOW0QDId4A= =hEE3 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Pint symbols: YUCK!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Burgess wrote: | On Sun, 2008-02-24 at 16:46 +0200, Lauri Hahne wrote: | The old pint symbols look amateurish, the new ones only hideous. Just | take a look at http://informationfreeway.org/?lat=61.4978902211692lon=23.764454385823434zoom=16layers=F0B0F | | | That looks like a few streets with lots of bars. I don't see anything | wrong with it. | | What do you want it to look like? A different symbol? Not to show the | pub symbol? Show more of other symbols? Buildings outlines being shown? I think the symbol is fine, but there seems to be a line of white pixels on the right hand edge, which looks like it might be a rendering error. I'm not sure that pubs are more important than many other features of the map that are not shown - for example shops. If it were my map, I would remove pubs and put them in some sort of clickable overlay. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHwfxwz+aYVHdncI0RAi6XAJ9pKtNr8b/GVpPuzMFTnE4Ec/Aq4QCePYeA BA3lHwnflfB6tigz4kvcjH4= =P6n3 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Continuous audio in JOSM on tracks without waypoints
David Earl skrev:
On 24/02/2008 22:16, 80n wrote:
David
I gave it a try today. The results were excellent.
Do you have any feeling for how accurate the timer on your audio was by
the end of the session?
I have some feedback:
1) I found synchronising to be a bit tricky the first time you do it.
This wasn't helped by the fact that I had 20 minutes of tracks before I
started the audio recorder. I've updated the wiki with what I hope are
clearer and better instructions.
That was only relevant to the non-waypoint version, so I just moved it
up a bit into that section. If you're using waypoints, you'd always sync
on a GPS-defined marker, and it is much easier.
Your instructions are spot on though for the non-waypoint case.
2) While audio is playing, when I clicked on an audio marker it caused
JOSM to hang.
OK. I'll see if I can reproduce it. Can you be more specific?
3) The Open dialog for audio files does not appear to remember the last
place that was used. Other open dialogs in JOSM do.
Curious. I'm not aware of doing anything different. Maybe there is an
extra step I missed.
4) It would be nice to have keyboard shortcuts for Forward and Backwards.
OK, can be arranged I'm sure. How about '[' and ']' with '{' and '}' for
next and last marker? Assuming the system will let me do that - it
wouldn't let me have the spacebar for the play /pause for reasons I
don't understand.
5) It would be nice to hide the audio markers without also hiding the
orange cursor. I don't use waypoints and found that using the orange
cursor and the forward and backward buttons was all that I needed most
of the time.
I'm surprised your audio was dense enough that you didn't have to jump
to new locations using the markers - I get minutes of silence when I'm
audio mapping. My two hour expedition on Saturday generated 140-odd
waypoints, roughly one a minute.
But again, I imagine that wouldn't be too hard. I hadn't actually
realised the play head vanished with the markers. I guess the graphics
context I'm given to paint with is that for the layer.
6) Lastly, it would be really nice if it was possible to play the audio
at varying speeds. For long roads if I've made occasionals marks I don't
really want to listen to the whole recording in real time, but there's
not really any way of knowing where the next one will be without
listening to the whole recording.
That's why creating waypoints help, but I know from experience with my
Garmin, the combination of key presses makes in unfeasible while moving
on a bike. The single tap on my adapted version of MaemoMapper on the
Nokia is much, much better in this respect.
If you're on a bike though you could mimic waypoints though - if you
adopt a procedure where you always either speak just after you turn into
a junction or when you do a loop loop in the road, then you can use the
artificial markers to speed up jumping through the sound track.
Variable play speed would help with this.
I imagine I could fake the sample rate, or something like that. I'll
investigate. This is probably a bit more complicated than the rest.
Overall I really like it :)
Thanks. My feeling is that it makes me safer when I'm out mapping,
because I don't have trailing wires and don't have to keep pressing the
pause on my recorder.
David
Could this work with video media files ? I've invested in an Oregon
Scientific ACT2000 solid state helmet cam ( http://tinyurl.com/22zaep )
for use when driving my cityscooter. It has audio input too, but the
audio tends to be drowned out by the motor and wind sounds. I'm planning
on using it when mapping, logging data for Wigle and OSM on the laptop
and the Magellan CrossoverGPS, and filming the route as well as
roadsigns with the helmet cam (sample movie in DivX format on
http://www.stage6.com/user/DutchDK ).
Loading up the stream and seeing it in a seperate window in sync with
the gpx log in JOSM could be great ;)
Dutch
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Continuous audio in JOSM on tracks without waypoints
On 25/02/2008, J.D. Schmidt [EMAIL PROTECTED] wrote: Could this work with video media files ? I've invested in an Oregon Scientific ACT2000 solid state helmet cam ( http://tinyurl.com/22zaep ) for use when driving my cityscooter. It has audio input too, but the cool, will you be contributing the videos to openstreetview.org ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Continuous audio in JOSM on tracks without waypoints
Robin Paulson skrev: On 25/02/2008, J.D. Schmidt [EMAIL PROTECTED] wrote: Could this work with video media files ? I've invested in an Oregon Scientific ACT2000 solid state helmet cam ( http://tinyurl.com/22zaep ) for use when driving my cityscooter. It has audio input too, but the cool, will you be contributing the videos to openstreetview.org ? If you set up that site, you can just link to the files on stage6 - saves me from uploading the multiple MB video files to two places... ;) Seriously though, driving the scooter or the MC, while attempting to take snapshots of roadsigns is detrimenttal to your health, and that is what prompted me to purchase the helmetcam. If the resulting video stream could be utilized in conjunction with a GPX tracklog in JOSM, in the same way as an audio stream, it would be another great way of documenting the names of roads. Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: Again, look at the visualization of the data as a seperate entity - related to, and an important part of OSM, but not the defining measure of OSM. An example (graphic to fit my reputation ofcourse.. You have been duly warned ;) ) : If I decided to map all the trees I have taking a leak up at on the way home from drinking bouts the last couple of years, I can do so. I'll just tag it with k=urinated_tree_were_the_leaves_has_become_yellow_brownish_in_colour v=200 ml used and processed beer/. I could even tag the same tree multiple times, depending on whether I took the piss at the north, east, west, or south side of the tree. And I could even use a different tagname such as k=Urinerede_Træer_som_har_blade_med_gul_brunlig_kulør v=200 ml brugt øl without any problems. This points out the wiki-like outlook on our DB. The tag and data has only mildly interest for anybody else, but it might have real value for me. I could be the type that tends to loose my keys everytime I take a leak in toxicated condition, and now I have the possibilty to see where I have been, and go look for them. Or maybe I'm making a map showing which trees not to sit under during summer. Whatever the reason, it's geodata, and valid to go into the DB or the 80GB of cryptic XML as you called it. It might be useless for anybody else, but it wouldn't be to me. AND it could become usefull for someone else later on (urologists researching maximum distance intoxicated people can go between leaks, city planners looking for information on best placement of public restrooms, etc, etc). That would be a statistically very poor sample to base conclusions on, if you would be the only one doing that. If you want others to also start tagging trees that way, you're going to have to find some kind of agreement - that's where map features comes in... Polyglot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [talk-au] Deleting some GNB names..
It is probably a historical rural hamlet or locality that no longer exists, but is still recorded in the GNB database. If you could find local references to it, I would probably change it to a place=locality, otherwise just delete it. Brent I've deleted a few of GNB added names over the past week. They seem to be rural localities added within Sydney. For example Murphy Heights. It has an entry in Australian Place Names, at ga.gov.au, but + it is not in the Australian Postcode list + a google search returns no residences in that suburb + it is not on the NSW lands dept list of addresses + there are no signs, or local information referring to the area I'm now suspicious of any of the GNB entries which claim to be rural areas within the Sydney metro. Anybody see any reason why we need to keep these, or know of their origin/reason for existance? Ian. Brent Easton Analyst/Programmer University of Western Sydney Email: [EMAIL PROTECTED] ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [Talk-de] WMS Server
Hallo, Schöner wäre natürlch wenn jemand JOSM beibringen würde mit der GK Projektion umzugehen. Hmpf, hab das ja in Berlin neulich schon versprochen... aber ich habs wirklich fest vor, es ist bestimmt nur ne Kleinigkeit ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM Entwicklung und Plugin News
Hallo, Ich meinte auch etwas darüber gelesen zu haben, das man die Tile-Server-Source für die Slippy map nun setzen könnte. Leider finde ich auf der Plugin-WIKI-Seite auf die verwiesen wird nur folgende Info: The plugin installs a dropdown in the main preferences window. Here you can select your desired tile source. Wenn ich nun das 'Prefernces Window' aufmache finde ich nichts was nur annähernd vom Namen her zu 'slippy_map_chooser' passt. Das Plugin, das die Slippy Map im Hintergrund zeigt, heisst slippymap, nicht slippy_map_chooser; bist Du sicher, dass Du das ueberhaupt installier hast? Dann findest Du die gewuenschte Dropdown-Box ganz untern auf dem ersten Preferences-Screen (der, auf dem man auch die Farben auswaehlt). Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] WMS Server
Hi Christopher, wir hatten diese Diskussion schonmal letztes Jahr auf der Liste. NRW stellt eine ganze Reihe von WMS-Diensten zur Verfügung: http://www.geoserver.nrw.de/gbdatenLDS.html Mit folgenden Link kann man dann z.B. die Orthophotos mittels WMS-Plugin in JOSM anschauen: http://www.gis2.nrw.de/wmsconnector/wms/luftbild?SERVICE=WMSVERSION=1.1.0REQUEST=GetMapLAYERS=Orthophoto+Str.+2,Orthophoto+Str.+3FORMAT=image%2FpngTRANSPARENT=TRUEsrs=EPSG:4326STYLES=VERSION=1.1.0 Aber nur das reine Betrachten ist zum Privatgebrauch gestattet. Eine Wiki-Seite zu erstellen, oder die Links fest ins Plugin einzubauen wäre natürlich kein Problem, aber dann würden unbedarfte Nutzer mir nix dir nix anfangen danach zu mappen und OSM hätte ein rechtliches Problem... MfG Tino Am 22.02.08 schrieb Christopher Dyrlich [EMAIL PROTECTED]: Hallo, Könnt ihr mir bitte mal nen paar WMS Server nennen, die ich auch in JOSM einbinden kann? Den ich kann mit den Yahoo Luftaufnahmen einfach nix anfangen, da die Auflösung von dennen einfach viel zu schlecht ist um etwas zu erkennen, und ich habe wirklich keine Lust, nodes auf gut glück zu setzen und zu verbinden, dafür bin ich einfach zu perfektionistisch veranlagt. Ich wäre sogar schon mit Luftaufnahmen aussen zweiten Weltkirieg zufrieden, da ich nicht glaube, das sich bei mir in der gegend in den letzten Jahren so dermaßen viel verändert hat, das man diese nicht mehr benutzen kann. bzw.. Geht es mir hier um Aufnahmen vom Ruhrgebiet. mfg, Christopher ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] WMS Server
Frank Jäger [EMAIL PROTECTED] wrote: Da eigentlich alle WMSse im EPSG 4326 liefern können, braucht man keinen Mapserver zwischenschalten, der den WMS kaskadiert. Der M$ Schrott von lv-bw kann definitiv kein epsg:4326 liefern sondern nur epsg:31467. Gruss Sven -- In my opinion MS is a lot better at making money than it is at making good operating systems (Linus Torvalds, August 1997) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] WMS Server
Andreas Hubel [EMAIL PROTECTED] wrote: gibts ne Anleitung dafür? Ich hab ein funktionierendes Mapfile für http://www.lv-bw.de allerdings werde ich das erst mal nicht posten, weil eben gerade nicht geklärt ist inwiefern die Verwendung für OSM in Ordnung ist. Der Abstrakt unter http://www.lv-bw.de/dv/capabilities.xml Erlaubt die Nutzung für Testzwecke und GDI-Projekte, was auch immer das ist. Der rest des Textes bezieht sich wie üblich auf die Daten selbst und leider nicht auf Daten die unter Verwendung des Materials erstellt wurden. Gruss Sven -- Software patents are the software project equivalent of land mines: Each design decision carries a risk of stepping on a patent, which can destroy your project. (Richard M. Stallman) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wanderwege, Klettersteige, Kletterfelsen
4) Wanderkarte fürs Garmin erstellen (ähnlich wie die Fahrradkarte) Zwecks Reklame würde es evtl. auch Sinn machen, einen überregionalen Fahrradweg zu erfassen, z.B. Maintalradweg. Aber dazu ist das Wetter noch nicht so ideal... Diese ominösen D-Routen sollte man erfassen. Das eckl durch N habe ich so ziemlich im kasten. Gibt es die jetzt oder gibt es sie nicht? Ich meine ein bundesweites Fahrradnetz (ncn) - Ich war bisher der Überzeugung, daß soetwas in Deutschland nicht existiert. Aber jetzt habe ich nach dem letzten update der Fahrradkarte das hier gesehen: http://www.gravitystorm.co.uk/osm/?zoom=9lat=6741680.63516lon=1019879.29899layers=B00 Ist das was offizielles? Ich habe in den letzten Wochen begonnen, Teilstücke des Radverkehrsnetzes NRW als rcn einzutragen (http://www.gravitystorm.co.uk/osm/?zoom=12lat=6564748.06228lon=787415.2371layers=B00), von daher interessiert mich die Thematik jetzt doch mal... MfG, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] WMS Server
Frank J?ger [EMAIL PROTECTED] wrote: Da eigentlich alle WMSse im EPSG 4326 liefern k?nnen, braucht man keinen Mapserver zwischenschalten, der den WMS kaskadiert. Soweit ich die OGC-Empfehlungen kenne, gibt es ekine Verpflichtung, Daten in bestimmten Bezugssystemen zu liefern (auch wenn EPSG 4326 wünschenswert wäre). Somit steht es auch dem lv-bw frei, Daten im Bezugssystem epsg:31467 auszuliefern. Mit freundlichen Grüßen / Regards / Cordialement Dr. Franz-Josef Behr We don't know the OS that God uses, but the Vatican uses Linux (Sister Judith Zoebelein, Vatican Webmaster) Prof. Dr. Franz-Josef Behr - Home Office Author of: Strategisches GIS-Management - http://www.gis-management.de eMail: [EMAIL PROTECTED] http://www.gis-news.de Tel: +49 (0)721 / 453980-1 sowie 45 33 35 Fax: +49 (0)721 / 453980-7 sowie via web.de: +49 (0)1212-5-12048213 [EMAIL PROTECTED] schrieb: Send Talk-de mailing list submissions to talk-de@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-de digest... Today's Topics: 1. Re: Wanderwege, Klettersteige, Kletterfelsen (Karl Eichwalder) 2. Re: Garmin-Karten von mapomatic (Christoph Eckert) 3. Re: Geocaches in OSM (vorher: Garmin-Karten von mapomatic ) (Christoph Eckert) 4. Re: Geocaches in OSM (vorher: Garmin-Karten von mapomatic) (Christoph Eckert) 5. Re: WMS Server (Frederik Ramm) 6. Re: JOSM Entwicklung und Plugin News (Frederik Ramm) 7. Re: WMS Server (Tino Miegel) 8. Re: WMS Server (Sven Geggus) 9. Re: WMS Server (Sven Geggus) 10. Re: Wanderwege, Klettersteige, Kletterfelsen (Martin Simon) -- Message: 1 Date: Sun, 24 Feb 2008 04:40:15 +0100 (CET) From: Karl Eichwalder [EMAIL PROTECTED] Subject: Re: [Talk-de] Wanderwege, Klettersteige, Kletterfelsen To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain;charset=iso-8859-1 leider scheint da nicht wirklich was vorw?rts zu gehen: 1) Marking trails in Slovenia (wiki-Beitrag mit Zuordnung zu bestehenden tags, auch in englisch) 2) einige emails im Archiv, jedoch kein Hinweis auf etwas konkretes 3) Insgesamt scheinen einige Wanderwege in OSM erfa?t zu sein, jedoch nur als footway, track, nicht als Wanderweg XXX. 4) proposed feature marked_trail H?rt sich alles nicht optimal an ;) Das sollte wie die Radrouten ?ber relations erledigt werden. 2) Wirtsh?user/Brunnen/Quellen/Gipfel/Seilbahnen/Parkpl?tze/Parkm?glichkeiten/ Sehensw?rdigkeiten eingetragen Das ist jedenfalls gut :) 5) kurze St?cke (ca. 20-30km) vom Frankenweg (gesamt ca. 500km ??) erfa?t Alleine ist es schwierig, den gesamten Frankenweg zu erfassen. Andererseits k?nnte das eine gute Reklame abgeben diesen oder eine ?hnlichen Weg komplett in OSM zu haben. (Den Teil von Kronach bis Weismain kann ich erledigen, evtl. auch mehr) Um Gr?fenberg rum bin ich ca. 20 km des Frankenwegs abgelaufen. Davon sollten ca. 10 km in einer relation stecken. Die attribute der relation sind aber noch nicht optimal und angezeigt wird auch noch nichts. 7) lokalen Wanderverein kontaktiert: dort wird bereits mit GPS gearbeitet und alle betreuten/markierten Wege sind somit als Tracks verf?gbar. Erste (private) Telefonate ergaben, da? die Daten nicht so einfach herausger?ckt werden k?nnen, da die ja im Verein erstellt wurden. Ich denke, da mu? eben auf die Satzung und die Gemeinn?tzigkeit, etc. geachtet werden bzw. das Thema erst im Verein abgestimmt werden. Diese vereinsmeier sollten auf jeden fall mal ihre satzung durchlesen... 4) Wanderkarte f?rs Garmin erstellen (?hnlich wie die Fahrradkarte) Zwecks Reklame w?rde es evtl. auch Sinn machen, einen ?berregionalen Fahrradweg zu erfassen, z.B. Maintalradweg. Aber dazu ist das Wetter noch nicht so ideal... Diese omin?sen D-Routen sollte man erfassen. Das eckl durch N habe ich so ziemlich im kasten. -- Message: 2 Date: Sun, 24 Feb 2008 07:27:29 +0100 From: Christoph Eckert [EMAIL PROTECTED] Subject: Re: [Talk-de] Garmin-Karten von mapomatic To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=utf-8 Moin, blitzer dagegen waeren relativ interessant. allerdings ist das wohl rechtlich ein problem... ich bin pers?nlich auch gar nicht scharf
Re: [Talk-de] Anlegen von Flächen (landuse, lei sure etc.)
Sven Geggus schrieb: Christoph Eckert [EMAIL PROTECTED] wrote: Abweichend von meiner bisherigen Praxis habe ich dabei begonnen, die Flächen (und Straßen, schluck) auf gemeinsamen Knotenpunkten verlaufen zu lassen. Ehrlich gesagt mache ich das bei Straßen nicht so sondern nur bei Flächen z.B. Wald an Park und dergleichen. Sven ich auch... Elwood ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Taggen eines Wegweisers
Hallo! In der Schweiz gibt es entlang offizieller Wanderwege Wegweiser mit dem Namen der Region, der Höhe über Meer und den Richtungen mit Zeitangaben (für ein Beispiel siehe http://www.emmenthaler.ch/fotohpsiegenthaler/wegweiser.jpg). Wie sollte man das taggen? Ich habe nun einfach mal den Namen mit dem Schlüssel name und die Höhe mittels dem Schlüssel ele getaggt, weiss aber nicht wie ich den Wegweiser selbst auszeichnen soll. Gruss, Misch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wanderwege, Klettersteige, Kletterfelsen
Andreas Stenglein: Hallo, zum Thema Wandern/Klettern und OSM habe ich bisher nur folgendes gefunden, leider scheint da nicht wirklich was vorwärts zu gehen: 1) Marking trails in Slovenia (wiki-Beitrag mit Zuordnung zu bestehenden tags, auch in englisch) 2) einige emails im Archiv, jedoch kein Hinweis auf etwas konkretes 3) Insgesamt scheinen einige Wanderwege in OSM erfaßt zu sein, jedoch nur als "footway", "track", nicht als Wanderweg XXX. 4) proposed feature "marked_trail" Das habe ich bisher unternommen, mehr oder weniger intensiv/zielorientiert: 1) Fußwege/Wanderwege (vom Wochenende/Urlaub) eingetragen, teilweise einfach als footway, teilweise genauer klassifiziert (Fränkische Schweiz/Frankenwald/Fichtelgebirge/ Obermaintal/Alpen/Bayerischer Wald/Mallorca) 2) Wirtshäuser/Brunnen/Quellen/Gipfel/Seilbahnen/Parkplätze/Parkmöglichkeiten/ Sehenswürdigkeiten eingetragen 3) versuchsweise einen lokalen Wanderweg erfaßt und mit marked_trail=Mühlenweg getagged, leider fehlen da ringsum noch einige Straßen. Leider erscheint der Wanderweg auch nirgends, weil kein Renderer das tag auswertet noch das Mühlenwegsymbol kennt. 4) versuchsweise einige lokale Wanderwege teilweise erfaßt und teilweise mit marked_trail=yes oder marked_trail=3 , etc. getagged 5) kurze Stücke (ca. 20-30km) vom Frankenweg (gesamt ca. 500km ??) erfaßt Alleine ist es schwierig, den gesamten Frankenweg zu erfassen. Andererseits könnte das eine gute Reklame abgeben diesen oder eine ähnlichen Weg komplett in OSM zu haben. (Den Teil von Kronach bis Weismain kann ich erledigen, evtl. auch mehr) 6) alpin-koordinaten.de kontaktiert: keine Rückinfo. Dort werden bereits Tracks von Wanderwegen sowie Koordinaten von Alpenhütten, Gipfeln und Kletterfelsen gesammelt, allerdings sind diese Daten so wie sie dort angeboten werden kaum bzw. recht unpraktisch verwendbar, IMHO. Einfach in OSM kann man die jedoch auch nicht integrieren, dazu müßten die Leute dort ihre Zustimmung geben. 7) lokalen Wanderverein kontaktiert: dort wird bereits mit GPS gearbeitet und alle betreuten/markierten Wege sind somit als Tracks verfügbar. Erste (private) Telefonate ergaben, daß die Daten nicht so einfach "herausgerückt" werden können, da die ja im Verein erstellt wurden. Ich denke, da muß eben auf die Satzung und die Gemeinnützigkeit, etc. geachtet werden bzw. das Thema erst im Verein abgestimmt werden. Meine Einschätzung ist, daß langfristig gesehen prinzipiell "etwas gehen könnte", vorausgesetzt OSM kann den Wandervereinen auch etwas bieten. Das kann ich nicht (so einfach), denke aber daß es hilfreich wäre: 1) Renderer aufsetzen der durchsichtige Karte aus den "marked_trail"s erstellt, die man in der Slippy-map drüberlegen kann. Dazu sind später auch .svg Dateien der Wegsymbole nötig (z.B. stilisiertes Mühlrad: 4 Speichen, 12 Schaufeln, weiße 3 auf rotem Punkt) 2) Einen überregionalen Wanderweg komplett erfassen und taggen, zwecks "Reklame". Ggf. sollten da auch alle Wegkreuzungen, Denkmäler, Sehenswürdigkeiten am Weg gleich mit erfaßt werden, so daß daraus ein Roadbook des Weges erstellt werden kann. 3) weitere Wandervereine kontaktieren, OSM evtl. dort "professionell" vorstellen. 4) Wanderkarte fürs Garmin erstellen (ähnlich wie die Fahrradkarte) Zwecks Reklame würde es evtl. auch Sinn machen, einen überregionalen Fahrradweg zu erfassen, z.B. Maintalradweg. Aber dazu ist das Wetter noch nicht so ideal... viele Grüße, Andreas Stenglein Ui... Wanderwege sind nichts zum taggen, ganz im Gegenteil. Dafür sind die leider immer noch stiefmütterlich behandelten Relationen da, mit denen man mehere Ways zusammenfassen kann. Praktisch beispielsweise, wenn ein Radweg teilweise auf einer Bundesstraße verläuft. Siehe hierzu auch: http://wiki.openstreetmap.org/index.php/De:Germany_roads_tagging#Wanderwege und http://wiki.openstreetmap.org/index.php/Relations/Proposed/Routes Die Idee mit dem Kontakt zu Wander- und Klettervereinen ist ideal und ein guter Tipp für die lokale "Offroad"-Erfassung, speziell, da entsprechende GPS-Ausrüstung und -Erfahrung ja meist schon vorhanden ist. Grüße aus Leipzig Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] WMS Server
Dr. Franz-Josef Behr [EMAIL PROTECTED] wrote: Soweit ich die OGC-Empfehlungen kenne, gibt es ekine Verpflichtung, Daten in bestimmten Bezugssystemen zu liefern (auch wenn EPSG 4326 wünschenswert wäre). Somit steht es auch dem lv-bw frei, Daten im Bezugssystem epsg:31467 auszuliefern. Dass das Teil allerdings 31467 statt einer Fehelrmeldung liefert, wenn man 4326 anfordert ist defibnitiv kaputt. Sven P.S.: Im Dialogstil zitierte Email erhöhen die Lesbarkeit http://de.wikipedia.org/wiki/TOFU -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Ackerland
Am 24.02.08 schrieb Martin Simon [EMAIL PROTECTED]: Am 24.02.08 schrieb Claudius Henrichs [EMAIL PROTECTED]: Soweit ich das mitgekriegt habe, wird das so nur in Aachen von ein paar Leuten praktiziert - ganz ehrlich: ich halte das für großen Blödsinn.(vor allem die Begründung, die Flächen würden sonst zu groß) Full Ack! mir erschließt sich der Sinn statt der Info hier ist landwirtschaftlich genutzte Fläche lieber *keine Info* haben zu wollen auch irgendwie nicht .. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPX-route2osm?
Hi, gibts schon ein fertiges script oder xslt Stylesheet um aus GPX Routen OSM Dateien (Wege ohne Tag) zu machen oder muss ich mir da selbst was hacken? mach doch mit gpsbabel einen Track 'draus und lade/konvertiere den in JOSM. Best regards, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Ackerland
Moin, Auf der englischen Map-Feature-Seite steht davon nichts http://wiki.openstreetmap.org/index.php/Map_Features#Landuse landuse=farm: Animals, vegetables, flowers, fruit growing so verwende ich das auch. me too. Wird auch grün gerendert und nicht ziegelrot :) . Meines Erachtens ist das gerade für Äcker/Felder/Wiesen/Weiden gedacht. Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Problem bei upload mit JOSM
Hallo, beim Versuch Daten mit 'Upload to JOSM' hochzuladen öffnet sich ein Fenster: Enter Password incorrect password oder username Mein username und password sind eingetragen Der username ist richtig (wie bei preferences eingetragen) und auch eine erneute Eingabe des password und drücken von 'OK' zeigt erneut dieses Fenster an. Auch nach drücken von 'Abbrechen' erscheint das Fenster erneut. Abbruch ist nur über den Task-Manager oder Neustart möglich. MfG Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Überregionale Relationen für Routen , z.B. Radfernwege
Hallo, ich habe gerade mal testweise ein Stück des Schwarze-Laaber Radwegs entsprechend http://wiki.openstreetmap.org/index.php/Relations/Proposed/Routes#Cycle_Routes_in_Use als regional cycle route getaggt. Bin gespannt, wie das dann in der Cyle map (http://www.gravitystorm.co.uk/osm/) aussehen wird. Da stelle ich mir die folgende Frage: Wie kann gewährleistet werden, dass bei längeren Radwegen überall die gleiche Relation verwendet wird? [ Der Donauradweg hat z.B. laut http://de.wikipedia.org/wiki/Liste_der_Radfernwege_in_Deutschland eine Länge von 1260km und das auch noch länderübergreifend ...] D.h. wie findet z.B. der Mapper aus Ulm die Donauradweg Relation, die beispielweise ich ein paar Tage vorher im Raum Regensburg angelegt habe? Ich vermute mal, dass der JOSM immer nur die Relationen lädt, die irgendeinem Objekt im aktuellen Kartenausschnitt zugeordnet sind, oder? Das war heute mein erster echter Kontakt mit dem Konzept der Relationen, bestimmt können mir die Experten da weiterhelfen... Ist es eigentlich im JOSM möglich, alle ways, die zu einer Relation gehören, farblich hervorzuheben? Ich habe das gerade mit JOSM ... proberit, aber nichts entsprechendes gefunden. Stopp - das geht doch: im Relation Editor alle Members markieren und auf Select klicken. Super! Viele Grüße, Helmut - Lesen Sie Ihre E-Mails auf dem Handy.. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Überregionale Relationen für Routen , z.B. Radfernwege
H. Schmidt schrieb: ich habe gerade mal testweise ein Stück des Schwarze-Laaber Radwegs entsprechend http://wiki.openstreetmap.org/index.php/Relations/Proposed/Routes#Cycle_Routes_in_Use als regional cycle route getaggt. Bin gespannt, wie das dann in der Cyle map (http://www.gravitystorm.co.uk/osm/) aussehen wird. Sehr schön, habe mich heute auch mal schlau gemacht was für Radwege hier bei mir so vorbei kommen und werde demnächst die Erfassung beginnen. Da stelle ich mir die folgende Frage: Wie kann gewährleistet werden, dass bei längeren Radwegen überall die gleiche Relation verwendet wird? [ Der Donauradweg hat z.B. laut http://de.wikipedia.org/wiki/Liste_der_Radfernwege_in_Deutschland eine Länge von 1260km und das auch noch länderübergreifend ...] D.h. wie findet z.B. der Mapper aus Ulm die Donauradweg Relation, die beispielweise ich ein paar Tage vorher im Raum Regensburg angelegt habe? Ich vermute mal, dass der JOSM immer nur die Relationen lädt, die irgendeinem Objekt im aktuellen Kartenausschnitt zugeordnet sind, oder? Da wird es hoffentlich mal eine Funktion zum vereinen von Relationen geben, so wie es bei Wegen schon geht. Da hat man zwar anfangs immer noch mehrere Relationen für verschiedene Wegabschnitte aber immer wenn man die Lücke zwischen Zweien einzeichnet würde man die beiden Relationen vereinen und hätte am Ende (wenn der Weg komplett erfasst ist) nur eine einzige Relation. Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Problem bei upload mit JOSM
dieter jasper [EMAIL PROTECTED] writes: Hallo, beim Versuch Daten mit 'Upload to JOSM' hochzuladen öffnet sich ein Fenster: Enter Password incorrect password oder username Es gibt bei Openstreetmap 2x Username und Passwort. Einmal für das Wiki und ein anderes Mal für die Datenbank. JOSM benötigt die UserID und das Passwort für die Datenbank. Einen Account für die Datenbank kann man hier erstellen: http://www.openstreetmap.org/create-account.html Die User-ID ist dann normalerweise die Email-Adresse. Ich habe irgendwo gelesen, dass man als Passwort für die Datenbank kein besonders wichtiges verwenden soll, da dieses irgendwo einfach ausgelesen werden kann. Longbow4u ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Problem bei upload mit JOSM
Hallo, beim Versuch Daten mit 'Upload to JOSM' hochzuladen öffnet sich ein Fenster: Enter Password incorrect password oder username Mein username und password sind eingetragen Der username ist richtig (wie bei preferences eingetragen) und auch eine erneute Eingabe des password und drücken von 'OK' zeigt erneut dieses Fenster an. Es kommt dabei darauf an, dass Du den gleichen Usernamen und das gleiche Password wie beim Server benutzt. Also, um Missverstaendnisse auszuschliessen, geh mal auf www.openstreetmap.org oben rechts auf log in und gib dort Usernamen und Passwort ein. Klappt es hier mit den Daten, mit denen es in JOSM nicht klappte? Dann ist es ein JOSM- Problem. Klappt es auch hier nicht, dann hast Du schlicht Dein Passwort vergessen ;-) (Hast Du zufaellig zwischenzeitlich einen passwortgeschuetzten WMS-Server benutzt? Dann hat JOSM das gespeicherte API-Passwort ueberschrieben...) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Problem bei upload mit JOSM
Frederik Ramm schrieb: Hallo, beim Versuch Daten mit 'Upload to JOSM' hochzuladen öffnet sich ein Fenster: Enter Password incorrect password oder username Mein username und password sind eingetragen Der username ist richtig (wie bei preferences eingetragen) und auch eine erneute Eingabe des password und drücken von 'OK' zeigt erneut dieses Fenster an. Es kommt dabei darauf an, dass Du den gleichen Usernamen und das gleiche Password wie beim Server benutzt. Also, um Missverstaendnisse auszuschliessen, geh mal auf www.openstreetmap.org oben rechts auf log in und gib dort Usernamen und Passwort ein. Klappt es hier mit den Daten, mit denen es in JOSM nicht klappte? Mein Fehler, kein JOSM-Problem. Login bei openstreetmap.org erfordert ein anderes Passwort als das was bei JOSM eingetragen war. Mir ist es nicht aufgefallen, da das Passwort gespeichert ist und so voreingetragen war. Aber warum bricht der Button 'Abbrechen' nicht ab? MfG Dieter Jasper Dann ist es ein JOSM- Problem. Klappt es auch hier nicht, dann hast Du schlicht Dein Passwort vergessen ;-) (Hast Du zufaellig zwischenzeitlich einen passwortgeschuetzten WMS-Server benutzt? Dann hat JOSM das gespeicherte API-Passwort ueberschrieben...) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wanderwege, Klettersteige, Kletterfelsen
Am 24.02.2008 04:40:15 schrieb(en) Karl Eichwalder: 5) kurze Stücke (ca. 20-30km) vom Frankenweg (gesamt ca. 500km ??) erfaßt Alleine ist es schwierig, den gesamten Frankenweg zu erfassen. Andererseits könnte das eine gute Reklame abgeben diesen oder eine ähnlichen Weg komplett in OSM zu haben. (Den Teil von Kronach bis Weismain kann ich erledigen, evtl. auch mehr) Um Gräfenberg rum bin ich ca. 20 km des Frankenwegs abgelaufen. Davon sollten ca. 10 km in einer relation stecken. Die attribute der relation sind aber noch nicht optimal und angezeigt wird auch noch nichts. Ich habe nun deinem Frankenweg ein paar Kilometer nordwestlich von Kulmbach zugefügt. Ist das ok? Eine Slippy-Wanderkarte wäre natürlich eine gute Motivation da etwas intensiver dran zu bleiben... dann dann Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM Entwicklung und Plugin News
Frederik Ramm schrieb: Hallo, slippymap Version 5692 habe ich auch installiert. Gleiche Version bei mir. In der Preferences Liste sehe ich folgende Punkte: Anzeige-Einstellungen Bei mir englisch - ob das ein Problem sein koennte? Unter Anzeige-Einstellungen finde ich nur 'Verhalten und Aussehen' und 'Farben' da ist keine Dropdown-Box. Die Dropdown-Box ist bei mir etwas gequetscht unter den Farben, s. Screenshot. Bist Du sicher, dass Du die Version 5692 installiert hast (jar-Datei mit 18241 Bytes)? Die Plugin-Uebersicht in den preferences zeigt ja i.d.R. die neueste verfügbare Version an und nicht die gerade installierte... Hallo Frederik, jetzt funktioniert es ja bei mir, aber jetzt habe ich doch noch eine Frage. Ich kann mir die Slippymaps von telascience.org holen, möchte jedoch auch die Errors von http://tile.openstreetmap.nl/coastlines.html sehen. Geht das? und wie? Danke mikes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Überregionale Relationen für Routen , z.B. Radfernwege
Hi, Da wird es hoffentlich mal eine Funktion zum vereinen von Relationen geben, so wie es bei Wegen schon geht. Da hat man zwar anfangs immer noch mehrere Relationen für verschiedene Wegabschnitte aber immer wenn man die Lücke zwischen Zweien einzeichnet würde man die beiden Relationen vereinen und hätte am Ende (wenn der Weg komplett erfasst ist) nur eine einzige Relation. man könnte natürlich auch an eine Hierarchie denken. Jeder mappt seinen Teilweg, und am Ende steckt man die Teile in eine übergeordnete Relation. Oder sind konzeptuell Hierarchien von Relationen nicht vorgesehen? Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Anlegen von Flächen (landuse, leis ure etc.)
Hi, Abweichend von meiner bisherigen Praxis habe ich dabei begonnen, die Flächen (und Straßen, schluck) auf gemeinsamen Knotenpunkten verlaufen zu lassen. Das finde ich topologisch richtiger und sieht auch im Rendering wesentlich besser aus. danke für die Kommentare. Ich kam just heute durch solches Gebiet. Ein Nacheditieren ist einfach grausam. Den Tipp Flächen über gemeinsame Nodes, Straßen aber über eigene Nodes zu schicken, werde ich ab sofort beherzigen. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM Entwicklung und Plugin News
Hallo, jetzt funktioniert es ja bei mir, aber jetzt habe ich doch noch eine Frage. Ich kann mir die Slippymaps von telascience.org holen, möchte jedoch auch die Errors von http://tile.openstreetmap.nl/coastlines.html sehen. Das sind doch die von telascience, oder? Wenn Du die coastlines-URL aufrufst und dann mal rechtsklickst und den URL von so einem einzelnen Bild anguckst, kommt der doch genau vom telascience-Server. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Überregionale Relationen für Routen , z.B. Radfernwege
Christoph Eckert schrieb: Hi, Da wird es hoffentlich mal eine Funktion zum vereinen von Relationen geben, so wie es bei Wegen schon geht. Da hat man zwar anfangs immer noch mehrere Relationen für verschiedene Wegabschnitte aber immer wenn man die Lücke zwischen Zweien einzeichnet würde man die beiden Relationen vereinen und hätte am Ende (wenn der Weg komplett erfasst ist) nur eine einzige Relation. man könnte natürlich auch an eine Hierarchie denken. Jeder mappt seinen Teilweg, und am Ende steckt man die Teile in eine übergeordnete Relation. Oder sind konzeptuell Hierarchien von Relationen nicht vorgesehen? Ich hoffe stark, dass Relationen andere Relationen enthalten können und glaube auch das es so vorgesehen ist (nur halt noch nicht in JOSM implementiert). In diesem Fall sehe ich aber nicht den Sinn darin (höchstens als übler Workaround). Außer die Route ist explizit in einzelne Etappen unterteilt, was sich auch vor Ort entsprechend wiederspiegelt. Dann wäre eine solche Subuntergliederung evtl. gar nicht verkehrt. Aber das jeder Mapper seine Abschnitte als Relation zusammenfasst und die dann in den großen Suppentopf Überrelation wirft halte ich für arg unelegant. Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Überregionale Relationen für Routen , z.B. Radfernwege
Hallo, Ich hoffe stark, dass Relationen andere Relationen enthalten können und glaube auch das es so vorgesehen ist (nur halt noch nicht in JOSM implementiert). Denke schon... wenn Du es schaffst, eine Relation zu selektieren (z.B. ueber die Suchfunktion), muesstest Du sie ueber add selected im Relationen-Editor einer anderen hinzufuegen koennen. Dass das nicht komfortabel ist, steht auf einem anderen Blatt... ich habe mich bislang darum gedrueckt, hier viel Gehirnschmalz zu investieren, weil ich immer dachte, ich gebe dann zu stark vor, was man machen soll, und am Ende bin ich schuld, wenn alles Mist ist ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Überregionale Relationen für Routen , z.B. Radfernwege
Frederik Ramm schrieb: Denke schon... wenn Du es schaffst, eine Relation zu selektieren (z.B. ueber die Suchfunktion), muesstest Du sie ueber add selected im Relationen-Editor einer anderen hinzufuegen koennen. Dass das nicht komfortabel ist, steht auf einem anderen Blatt... ich habe mich bislang darum gedrueckt, hier viel Gehirnschmalz zu investieren, weil ich immer dachte, ich gebe dann zu stark vor, was man machen soll, und am Ende bin ich schuld, wenn alles Mist ist ;-) Bist du doch sowieso :-) Das mit der Suche geht ja tatsächlich, bin ich nicht drauf gekommen. Bis dir was besseres einfällt kannst du ja in das Realtionfenster einfach einen Select-Button packen. Oder man kann eine Relation über die Member Of-Liste selektieren. Aber irgendwie ist das gerade noch etwas inkonsistent mit den Relations, das die in zwei Listen auftauchen. Aber wenn man die häufiger benutzt wird sich schon ein Konzept ergeben. Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Überregionale Relationen für Routen , z.B. Radfernwege
Moin Bin gespannt, wie das dann in der Cyle map (http://www.gravitystorm.co.uk/osm/) aussehen wird. Ah, die kannte ich noch nicht... Nett... Aber ist es normal, dass bei Zoom=13 Schluss ist? Wenn man noch stärker zoomt, lädt er zwar fleißig, aber es bleibt weiß... Das ist gerade fürs Radeln etwas ungeschickt... Gruß Heiko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Überregionale Relationen für Routen , z.B. Radfernwege
Hallo, Aber irgendwie ist das gerade noch etwas inkonsistent mit den Relations, das die in zwei Listen auftauchen. Aber wenn man die häufiger benutzt wird sich schon ein Konzept ergeben. Was mir immer mal im Kopf rumschwirrt, ist was ganz altmodisches - so eine Art Excel-Ansicht im JOSM, wo man fuer jedes Objekt einfach einen Tabellen-Eintrag hat, und dass man dann zwischen der Karte und der Liste umschalten kann. Ich koennte mir vorstellen, dass das fuer einige Sachen ganz praktisch waere. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk-fr] Planet OSM-FR
Merci bien. On commence à avoir quelques trucs c'est cool. Je vais presque être obligé de me mettre à écrire également :) Je filerai l'URL quand j'aurais eu sxpert pour le nom de domaine. Renaud. On 2/24/08, Guilhem Bonnefille [EMAIL PROTECTED] wrote: Le 24/02/08, serge karamazov[EMAIL PROTECTED] a écrit : Bonjour, A la dernière (et première) réunion, il a été question de mettre en place un planet (aggrégateur de feeds RSS et autres provenant de sites français parlant d'OSM). J'ai un truc qui marche dans les cartons et je viens donc récolter des URLs pour l'alimenter. A votre bon coeur. Tenez mon brave. http://nathguil.free.fr/wordpress/?feed=rss2cat=12 Plus sérieusement, merci pour ce travail. -- Guilhem BONNEFILLE -=- #UIN: 15146515 JID: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] -=- mailto:[EMAIL PROTECTED] -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Planet OSM-FR
Thomas, j'aurais besoin d'un flux RSS pour cette catégorie si tu as. A moins que tu préfères que je mette le RSS du blog. C'est toi qui choise. Pour ce qui est de la fréquence c'est pas très grave, l'essentiel étant que le jour où tu postes quelquechose, il soit lu. Renaud. On 2/24/08, Thomas Walraet [EMAIL PROTECTED] wrote: serge karamazov wrote: A votre bon coeur. Bah j'ai une section carto sur mon blog, mais vu la fréquence de mise en ligne d'info intéressante je ne pense pas que ça vaille le coup de l'ajouter... http://thomas.walraet.net/blog/index.php/Cartographie (2006... je ne pensais pas que c'était à ce point avant de regarder...) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] export PDF pour impression de livre
On Sat, Feb 23, 2008 at 7:48 PM, Guilhem Bonnefille [EMAIL PROTECTED] wrote: Le 23/02/08, serge karamazov[EMAIL PROTECTED] a écrit : Pour du PDF, il y a ça : http://svn.openstreetmap.org/applications/rendering/imgAtlas/ et http://svn.openstreetmap.org/applications/rendering/pdf-atlas/ Je n'ai jamais essayé ce genre d'export, mais j'avais aussi vu passer des annonces concernant un export en postscript : osmps http://lists.openstreetmap.org/pipermail/dev/2007-July/006014.html et le soft sur http://svn.openstreetmap.org/applications/rendering/osmps/ Marc, si tu fais un comparatif, tiens-nous au courant de ton choix, s'il te plait. - imgAtlas marche plus ou moins bien, mais je n'arrive pas à le faire fonctionner sur les tuiles que je voudrais, - pdfAtlas nécessite de convertir un fichier .osm en format txt via un script perl, et j'ai un débordement de consomation memoire, cela monte au dela de 3Go et ca coince sur un OS 32 bits. Je regarderai du coté de tes liens Guilhem, merci pour les infos. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [Talk-us] OSM at LugRadio Live USA 2008
Adam I've forwarded this to the OpenStreetMap Foundation board, who can be contacted collectively at [EMAIL PROTECTED] Etienne On Sun, Feb 24, 2008 at 3:39 PM, Adam Sweet [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone I'm sorry to invade your list but I could find no other way of getting in touch with the right people and I was advised to do so on the #osm IRC channel. I apologise if I am breaking with good etiquette by posting this here and asking you to mail us back on show at lugradio dot org as I won't be staying subscribed to the list for more than a day or 2. I am sorry about that. Perhaps it would be helpful to put some contact details for things like this on the OSM website. I am organising the exhibition for LugRadio Live USA 2008, which is being held at the Metreon Theater in San Francisco on 12th and 13th April this year. We would like OSM to take part in the exhibition and so would be grateful if you could discuss whether you would be able to exhibit OSM on the above dates. I include our call for exhibitors email below. Many thanks, Adam Sweet ... Howdy As you may or may not be aware, the very first LugRadio Live USA in 2008 is taking place at The Metreon in San Francisco. The event will be happening on the 12th and 13th April 2008, and will provide the unique atmosphere of the UK event, but in glorious San Francisco. LugRadio Live has developed a strong reputation for providing a range of topics about free software, Open Source, digital rights, technology and more, a compelling list of speakers, exhibitors and birds of a feather sessions, and wrapping it all in a unique, fun, loose, social and inclusive event, which is often described as combining the atmosphere of a rock concert and a computer conference. At LugRadio Live USA 2008 we plan on bringing this unique atmosphere to the USA, and inviting around 30 speakers, a full cast of exhibiting projects and companies, an eclectic range of BOF sessions, and plenty of additional sessions such as our debate discussion panel, a showcase of five minute talks, tech demos, and of course a live recording of LugRadio in front of an audience. We expect around 500 - 700 attendees to the event. Anyway, to the business in hand... As mentioned, we'll be having an exhibition area where we want to have projects and companies who do cool things. In the past we've had open source projects showing off their work such as KDE, Gnome, and Ubuntu, companies who work with Linux like Neuros, and distributors like Sun, Red Hat and Novell. We were wondering whether you'd be interested in having an exhibition stand at the event this year? Exhibitor space is free; we don't charge, because LugRadio Live is a community event. The focus is on people having a great time, not in making money :-) We'd like it if your exhibition stand could be something fun and interactive, rather than just a table with leaflets and advertising. Another thing: as part of the event, we provide each attendee with a registration bag, containing some free items from different organisations. We try to keep the items in this bag as interesting as possible, and in the past this has included pens, badges, software, clothing and more. If you'd like to contribute something to the bag this year for LugRadio Live USA 2008, we'd be happy to include it. Both the goodie bag and an exhibition stand are excellent ways for you to be associated with a strongly community and Open Source focused event, and the demographic it attracts. For the bag, we will need 500 of whatever you choose to contribute, and all you need to do is ship them to us, there is no charge in addition to sending the items - we will add them to the bags ready for the event. LugRadio Live in the UK has developed a strong reputation for being 'the' community event in the UK, and we are looking to bring this to USA. We would love if you could be one of the organisations who helped make this happen. :) If you're not the right person to ask about attending, we'd be grateful if you could either pass it on to the right person for us or get back in touch to let us know who to contact. You can check who is speaking and how the event is shaping up by checking http://lugradio.org/live/USA2008/ Any questions or queries, feel free to drop us an email in reply to this email, and we really hope you can be a part of the event. :) Thanks! Adam Sweet and the LugRadio Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHwY+nRi1ZcmvD37cRAsA2AKDAcQKTuPeLwBJMwBqu11mOks3PzwCgjIam KuLYDQXUo9szLB3NA3bxRA0= =BCVy -END PGP SIGNATURE- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
