Re: [talk-ph] Boracay Spam
We should have it removed. It is not a map item, It is not helpful to the rest of the users of the system. It only benefits the single person and detracts from the others. If this continues we will remove the map from our website. This is the reason we use OSM since it is clean and done professionally and with out all those entries you see on other maps like. Freds house, where i lived as a child... Thats my two cents.. On Saturday 18 April 2009 23:35:59 Eugene Alvin Villar wrote: Based on the history, that data was created by Wtmitchell, the resident OSMer in Boracay, and the guy mentioned by Jim. So it's not really spam, but the data is of questionable value for OSM. On Sat, Apr 18, 2009 at 10:33 PM, Andre Marcelo-Tanner an...@enthropia.comwrote: I guess someone must have noticed our map already of Boracay, listing a lot for sale is spam right? http://www.openstreetmap.org.ph/map/c/11.92943501266/121.912386417388 92/17/ Andre ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Boracay Spam
I suggest we talk first to wmitchell (when the API 0.6 is live) On Mon, Apr 20, 2009 at 10:17 AM, Michael Cole colemic...@gmail.com wrote: We should have it removed. It is not a map item, It is not helpful to the rest of the users of the system. It only benefits the single person and detracts from the others. If this continues we will remove the map from our website. This is the reason we use OSM since it is clean and done professionally and with out all those entries you see on other maps like. Freds house, where i lived as a child... Thats my two cents.. On Saturday 18 April 2009 23:35:59 Eugene Alvin Villar wrote: Based on the history, that data was created by Wtmitchell, the resident OSMer in Boracay, and the guy mentioned by Jim. So it's not really spam, but the data is of questionable value for OSM. On Sat, Apr 18, 2009 at 10:33 PM, Andre Marcelo-Tanner an...@enthropia.comwrote: I guess someone must have noticed our map already of Boracay, listing a lot for sale is spam right? http://www.openstreetmap.org.ph/map/c/11.92943501266/121.912386417388 92/17/ Andre ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-legal-talk] [OSM-dev] Bittorrent
Hi, Francis Davey wrote: In almost all jurisdictions various information rights are property rights, which means they operate against everyone. The licence is a permission to use (say a work) without violation of the rights holders rights. I.e. the default is total restriction, which may only be bypassed via the licence. It is irrelevant whether a use of the information is aware of the licence since it is permissive not restrictive (although it may be constructed by stating exceptions to a generally given permission). Everything you say is true, but unless you have just joined the project you must be aware that the new license being contemplated - the Open Database License - rests heavily on the European idea of database rights, and tries to supplant them by a contract for jurisdictions that have no sui generis database protection. A contract of course requires agreement by those who are party to it before it can be of legal relevance. (Maybe you're reading this on dev and are unaware of the 1000+ postings in the previous year on legal-talk about the matter...?) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Tagging dangerous areas
Iván Sánchez Ortega wrote: I don't think OSM is the place for statistics... it has been said over and over map what is on the ground. But what we should be able to do is use the OSM data to easily correlate with available statistical sources, which means things like official boundaries and so on in the OSM dataset, so if someone said that statistically, the London Borough of Barnet has less car crime than Moss Side in Manchester, then it should be able to plot those areas on a map. Whether anyone would want to build such overlays into applications like a vehicle navigation system Find the nearest on-street free parking where I'll be able to come back and still likely find all my vehicle intact.. is another matter. Not that any of this matters. Crime maps and statistics are always retrospective. Any crime figures for my street show a very low crime level, but that didn't stop my house being burgled and my car vandalised in the space of a weekend. If we can come up with a method of providing a reliable crime forecast and put it on a map, you've got a very valuable product. If you leave your bicycle here after closing time at the local pub 'The Angle Grinder's tattood arms' then it's got a 25% chance of not being there tomorrow. -- Simon Hewison ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] the ref:color schema
There has been some discussion about what might be a similar problem on talk-us, where different states have different signs on Interstate highways. I have a few questions; it might be good to explain the answers on the tag proposal page. (I'm sure in .es the answers are obvious but I think road sign practices are quite different in the US so I don't understand.) Is the sign color part of a national/regional standard scheme? Typically, are all roads of the same administrative class having the same color signs? Or do roads of the same class have different color signs so people can follow the blue road or the yellow road in case reading numbers is confusing? Or does it tell you a road subclass - like the no roundabouts? In the US, the essence of the issue is that we have Interstate highways, which have a standard sign, but some states, especially California, have variants, and people want maps to show the local variants so they match what's on the ground. The proposal is to tag the road as being an interstate in California so the renderer can find the interstate/california sign variant. Then, there are US highways, which have similar signs most places. With state highways, each state has their own sign and color scheme. But I'm not aware of varying colors other than as part of a class of road. (I'm of course not trying to say your colors don't matter - just trying to tell you about our signs, so that any tagging schemes might be as general as they need to be.) Using ref:color means that has to match ref. So there's the question of when a physical stretch of road has two route numbers. (This happens often in the US and I would think it must be common in Europe as it's hard to avoid without having people not to be able to follow the lesser road.) It seems for that one needs to move to relations with no ref tags on ways, but only on the relation, and then the way can be in two route relations. So with that ref:color applying to ref works, but there has to be a one ref tag rule. Once you have ref=A19;C34 the ref:color seems unworkable. int_ref vs ref seems funny to me. E-5 is just another administrative classification, and the fact that it crosses country boundaries doesn't seem that much more important than say US highways crossing state boundaries. One of course needs to know the network and number, but a different tag feels denormalized (in the database schema sense). The US discussion on sign rendering seems to be headed towards network=us_i and ref=95 for Interstate 95 (I-95). I guess my biggest question is if the colors are arbitrary or they are encoding some property of the road. If they are telling people something about the road, then perhaps those rules are what should be encoded and then renderers should have access to the (jurisdiction,property)=color table. pgpOS2DIXT10n.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] the ref:color schema
El Domingo, 19 de Abril de 2009, Greg Troxel escribió: There has been some discussion about what might be a similar problem on talk-us, where different states have different signs on Interstate highways. [...] In the US, the essence of the issue is that we have Interstate highways, which have a standard sign, but some states, especially California, have variants, and people want maps to show the local variants so they match what's on the ground. Here in Spain (where this proposal comes from) we are in a very similar situation. The national scheme is quite clear, but lately, some regions* are starting to colour the road sings their own way just to stand out. * Technically, autonomous communities The proposal is to tag the road as being an interstate in California so the renderer can find the interstate/california sign variant. The main problem I see with this approach is the complexity of the rendering rules. There will be s many exceptions to the general rules that modifying the renderers will prove to be a daunting task. Using ref:color means that has to match ref. So there's the question of when a physical stretch of road has two route numbers. (This happens often in the US and I would think it must be common in Europe as it's hard to avoid without having people not to be able to follow the lesser road.) That's hard to find in europe AFAIK. There are the E-* signs, of course, but we have int_ref for those. Here in Spain, any big road sign will tell you the ref of the road you're in (top-center) *and* the refs of the roads it connects to (under the ref of the current road). It seems for that one needs to move to relations with no ref tags on ways, but only on the relation, and then the way can be in two route relations. +1. I guess my biggest question is if the colors are arbitrary or they are encoding some property of the road. If they are telling people something about the road, then perhaps those rules are what should be encoded and then renderers should have access to the (jurisdiction,property)=color table. The color encodes jurisdiction and administrative level. The problems I see are: - Sometimes, there are more real administrative levels than OSM administrative levels (i.e. yellow vs. purple tertiaries in Soria). - That table can be a *real* mess. Cheers, -- -- Iván Sánchez Ortega i...@sanchezortega.es Proudly running Debian Linux with 2.6.29-1-amd64 kernel, KDE 3.5.10, and PHP 5.2.9-1 generating this signature. Uptime: 16:33:40 up 2 days, 18:16, 4 users, load average: 0.57, 0.60, 0.54 signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] the ref:color schema
Iván Sánchez Ortega i...@sanchezortega.es writes: In the US, the essence of the issue is that we have Interstate highways, which have a standard sign, but some states, especially California, have variants, and people want maps to show the local variants so they match what's on the ground. Here in Spain (where this proposal comes from) we are in a very similar situation. The national scheme is quite clear, but lately, some regions* are starting to colour the road sings their own way just to stand out. * Technically, autonomous communities This sounds like a different issue than the main coloring, but maybe related to why it's hard. The proposal is to tag the road as being an interstate in California so the renderer can find the interstate/california sign variant. The main problem I see with this approach is the complexity of the rendering rules. There will be s many exceptions to the general rules that modifying the renderers will prove to be a daunting task. I am also starting to think that the US proposal to do us_i_ca for california interstate is maybe not the right answer. The road really is network=us_i but maybe needs a network:sign_variant=us_i_ca tag. Using ref:color means that has to match ref. So there's the question of when a physical stretch of road has two route numbers. (This happens often in the US and I would think it must be common in Europe as it's hard to avoid without having people not to be able to follow the lesser road.) That's hard to find in europe AFAIK. There are the E-* signs, of course, but we have int_ref for those. Here in Spain, any big road sign will tell you the I am not comfortable with int_ref; it seems to say there is a two-level hierarchy only and it seems the world is much more complicated. As an example, near me in the US you can be on a road which is both I-95 S and Massachusetts state route 128 south. Then there is an intersection where I-95 splits off. After the interchange you are on 128S and I-93N. This is funny that N/S are different, but the general case is quite common. Near me you can be on SR 117W, and then SR 62 merges in and you are on 117W/62W and then a few miles later there is a light and you can choose to turn left to stay on 62W or straight for 117W. But I think once you move to refs on relations and not on ways, this is no problem. I guess my biggest question is if the colors are arbitrary or they are encoding some property of the road. If they are telling people something about the road, then perhaps those rules are what should be encoded and then renderers should have access to the (jurisdiction,property)=color table. The color encodes jurisdiction and administrative level. The problems I see are: - Sometimes, there are more real administrative levels than OSM administrative levels (i.e. yellow vs. purple tertiaries in Soria). That sounds like something to be fixed, although it seems primary/secondary isn't fully about administrative levels - we have state highways tagged as motorway because they physically are. With network=us_sr_ma or whatever, more levels can be added to describe reality. - That table can be a *real* mess. Sure, that's the best argument for needing to encode colors. It just seems like if one can encode the administrative level etc. and map to colors that's far better - maybe there needs to be a databsae of the mapping that all renderers and other users can get at, sort of logically part of the database but not a node/way/relation. pgppeYmtsg67m.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] the ref:color schema
El Domingo, 19 de Abril de 2009, Greg Troxel escribió: I am also starting to think that the US proposal to do us_i_ca for california interstate is maybe not the right answer. The road really is network=us_i but maybe needs a network:sign_variant=us_i_ca tag. I think that usage of network=* is the right way to go (indeed, in Spain, every road *is* legally part of a network with a name). But keeping track of *all* road networks and their signage is going to be difficult. As an example, near me in the US you can be on a road which is both I-95 S and Massachusetts state route 128 south. Then there is an intersection where I-95 splits off. After the interchange you are on 128S and I-93N. Hm, sounds a little bit like the Nudo de la Paz[1] here in Madrid. You can be either in the M-30, M-11, A-1 or M-607 depending on the *lane*. [1] http://www.openstreetmap.org/?lat=40.48261lon=-3.68427zoom=15 But, yeah, relations are IMHO the way to go. - Sometimes, there are more real administrative levels than OSM administrative levels (i.e. yellow vs. purple tertiaries in Soria). That sounds like something to be fixed, although it seems primary/secondary isn't fully about administrative levels OK, but how do we fix this? - Do not use administrative levels for highway=* at all, as this info is somewhere else (network=* or even ref:color=* plus country). But then, what is highway=primary for?? - Use network=*, then assign highway=* depending on the importance of the network (or motorway for physical motorways), then get the shields through a batch process and a huge table. - That table can be a *real* mess. Sure, that's the best argument for needing to encode colors. It just seems like if one can encode the administrative level etc. and map to colors that's far better - maybe there needs to be a databsae of the mapping that all renderers and other users can get at, sort of logically part of the database but not a node/way/relation. Do you really think we can work that network-color table out, and make software that fits into osm2pgsql to derive the shields**? ** I don't like the word shield. We use frakking rectangles. Cheers, -- -- Iván Sánchez Ortega i...@sanchezortega.es MSN:i_eat_s_p_a_m_for_breakf...@hotmail.com Jabber:ivansanc...@jabber.org ; ivansanc...@kdetalk.net signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] the ref:color schema
Iván Sánchez Ortega i...@sanchezortega.es writes: As an example, near me in the US you can be on a road which is both I-95 S and Massachusetts state route 128 south. Then there is an intersection where I-95 splits off. After the interchange you are on 128S and I-93N. Hm, sounds a little bit like the Nudo de la Paz[1] here in Madrid. You can be either in the M-30, M-11, A-1 or M-607 depending on the *lane*. [1] http://www.openstreetmap.org/?lat=40.48261lon=-3.68427zoom=15 Wow, but here there's no lane notion. The whole road has multiple designations and it isn't weird. OK, but how do we fix this? - Do not use administrative levels for highway=* at all, as this info is somewhere else (network=* or even ref:color=* plus country). But then, what is highway=primary for?? highway=primary means that it's not a motorway or close, so that it isn't divided and restricted access with a high speed limit. And it means that it's a road that people use to go significant distances. Then ref=es_foo means it's a foo-type road in Spain, and the talk-es community can figure out what foo values are appropriate. This is about signs and legal status. (In US, it's interstate/ushighway/stateroute/countyroute mostly.) Around me SR 2 is a very important road. It's motorway in places, trunk in places, and primary the rest of the way. It is the main E/W road in the northern half of Massachusetts. So it's primary, even though it's not a US Highgway. Trying to make primary/secondary and administrative class always match seems not to be the OSM way - but I'm still pretty new so I could be off. - Use network=*, then assign highway=* depending on the importance of the network (or motorway for physical motorways), then get the shields through a batch process and a huge table. - That table can be a *real* mess. Sure, that's the best argument for needing to encode colors. It just seems like if one can encode the administrative level etc. and map to colors that's far better - maybe there needs to be a databsae of the mapping that all renderers and other users can get at, sort of logically part of the database but not a node/way/relation. Do you really think we can work that network-color table out, and make software that fits into osm2pgsql to derive the shields**? Sorry, shield is US-centric. Road sign characteristics (to include shape, color, font, etc). I think the table can be partially worked out, with the rest dealt with by tagging by exception on the roads that don't follow the rules. In the US having tags on interstates that say use normal interstate sign seems best avoided. If signs are not correlated with administrative designation, then I suppose each relation needs a road sign characteristic tag. pgp6zOJAa48oY.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Deriving reference numbers for L roads
I've come across a handy trick for determining the reference number for a L road here in Tipperary - the county council publishes the Speed Limit By-Laws; and nicely refers to most roads by the L-ref value. The by-laws are available for free download off their website. In most cases this makes it rather easy to determine what the reference number for a given road is if there's a speed-limit road-sign on it. Not all county-councils seem to follow this practice of identifying the roads in this manner, but where they do checking their By-Laws for such information is rather useful. hoping this helps, Ken -- http://short.ie/savenenaghhospital/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] the ref:color schema
2009/4/19 Iván Sánchez Ortega i...@sanchezortega.es: Do you really think we can work that network-color table out, and make software that fits into osm2pgsql to derive the shields? Remember that it doesn't need to be osm2pgsql to do this - large-scale .osm manipluation can be done with osmosis, and see also the TagTransform plugin. Overall, I'd rather see a lookup table of colours external to the osm data, and then have a lookup at some point in the rendering chain. It seems like a whole load of duplication of effort (and source of errors) to tag every way, and a colour-reliant renderer would need to cope with missing colour data so would end up needing the lookup table anyway. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] the ref:color schema
On Sun, Apr 19, 2009 at 05:20:09PM +0200, Iván Sánchez Ortega wrote: Do you really think we can work that network-color table out, and make software that fits into osm2pgsql to derive the shields**? ** I don't like the word shield. We use frakking rectangles. Like these ones? http://taphandles.go-ssl.com/store/images/_Rectangular%20Shield.jpg :D Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging dangerous areas
On Mon, Mar 30, 2009 at 6:33 PM, Matt Amos zerebub...@gmail.com wrote: On Mon, Mar 30, 2009 at 5:31 PM, MP singular...@gmail.com wrote: after the wembley mapping party last year i heard suggestions of a locals=angry tag. maybe we should expand that to include locals=violent or locals=heavily_armed? What happened at the Wembley mapping party? andy and steve independently attempted to map the same road on a council estate but both decided it might not be a wise idea. no violence was done i think, just evil stares. andy actually tagged it locals=angsty, rather than angry, but there is a precedent :-) http://www.openstreetmap.org/browse/way/27794700 I feel like I'm debating a point of order in a student union ( :-) ), but the encampment^Wstreet which Steve8 and I didn't want to map was this one, a short distance away: http://www.openstreetmap.org/browse/way/27693507 Also, if you check on the wiki, the locals=angsty is defined as implying the tag mapper=slightly_lazy and is often used on hot afternoons that bring out the worst in British council estate congregation behaviour. The tag doesn't apply during rain or winter conditions, but applies doubly shortly after football matches... Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] How is the upgrade going
I'm not on IRC, so I've got no idea, but anyone how the upgrade is going so far? Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How is the upgrade going
Maarten Deen schrieb: I'm not on IRC, so I've got no idea, but anyone how the upgrade is going so far? firefishy about 2h ago on twitter: migrating API 0.6 database - phase 5 (i started at the wrong number): re-creating consistent current tables. No major problems yet. Jonas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging dangerous areas
2009/4/20 Andy Allan gravityst...@gmail.com On Mon, Mar 30, 2009 at 6:33 PM, Matt Amos zerebub...@gmail.com wrote: On Mon, Mar 30, 2009 at 5:31 PM, MP singular...@gmail.com wrote: after the wembley mapping party last year i heard suggestions of a locals=angry tag. maybe we should expand that to include locals=violent or locals=heavily_armed? What happened at the Wembley mapping party? andy and steve independently attempted to map the same road on a council estate but both decided it might not be a wise idea. no violence was done i think, just evil stares. andy actually tagged it locals=angsty, rather than angry, but there is a precedent :-) http://www.openstreetmap.org/browse/way/27794700 I feel like I'm debating a point of order in a student union ( :-) ), but the encampment^Wstreet which Steve8 and I didn't want to map was this one, a short distance away: http://www.openstreetmap.org/browse/way/27693507 Also, if you check on the wiki, the locals=angsty is defined as implying the tag mapper=slightly_lazy and is often used on hot afternoons that bring out the worst in British council estate congregation behaviour. The tag doesn't apply during rain or winter conditions, but applies doubly shortly after football matches... After reading this thread and the comments on the diary post, I decided to see if there was any streetview there now... So, I entered Lynton Close, Wembley into the Google Maps find box and these were the first and third results... Mr T Blairhttp://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=lynton+close,+wembleyvps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563ie=UTF8latlng=42945511,-81211446,8277933314319449699ei=4FnrSaawL5OyiAO7v6nNAQcd=1 - more info »http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=lynton+close,+wembleyvps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563ie=UTF8latlng=42945511,-81211446,8277933314319449699ei=4FnrSaawL5OyiAO7v6nNAQcd=1 10 Downing Crescent, London, ON N6C, Canada - +44 7866 607197Unverified listing Write a reviewhttps://www.google.com/accounts/ServiceLogin?service=localhl=ennui=1continue=http://maps.google.com/maps%3Ff%3Dq%26source%3Ds_q%26hl%3Den%26geocode%3D%26q%3Dlynton%2Bclose,%2Bwembley%26vps%3D1%26jsv%3D154c%26sll%3D37.0625,-95.677068%26sspn%3D50.424342,79.101563%26ie%3DUTF8%26ei%3D4FnrSaawL5OyiAO7v6nNAQ%26dtab%3D2%26cid%3D42945511,-81211446,8277933314319449699%26iwd%3D1%26iwloc%3DA%26action%3Dopen The Committee will continue to keep all the issues covered by the Sixth Report under *close* review, while also continuing to fulfil its terms of reference by *...* cabinetoffice.gov.ukhttp://maps.google.com/local_url?q=http://archive.cabinetoffice.gov.uk/standards/publications/6th_report/correspondence/neill_blair.htmldq=lynton+close,+wembleyf=qsource=s_qoutput=jshl=engeocode=vps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563s=ANYYN7kCez7hisFRCZIbWnItF_cyjINxcA Gordon Brown'shttp://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=lynton+close,+wembleyvps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563ie=UTF8latlng=42945511,-81211446,1473789639052526619ei=4FnrSaawL5OyiAO7v6nNAQcd=3 - more info »http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=lynton+close,+wembleyvps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563ie=UTF8latlng=42945511,-81211446,1473789639052526619ei=4FnrSaawL5OyiAO7v6nNAQcd=3 10 Downing Crescent, London, ON N6C, Canada - +32 2 298 75 00Unverified listing Write a reviewhttps://www.google.com/accounts/ServiceLogin?service=localhl=ennui=1continue=http://maps.google.com/maps%3Ff%3Dq%26source%3Ds_q%26hl%3Den%26geocode%3D%26q%3Dlynton%2Bclose,%2Bwembley%26vps%3D1%26jsv%3D154c%26sll%3D37.0625,-95.677068%26sspn%3D50.424342,79.101563%26ie%3DUTF8%26ei%3D4FnrSaawL5OyiAO7v6nNAQ%26dtab%3D2%26cid%3D42945511,-81211446,1473789639052526619%26iwd%3D1%26iwloc%3DA%26action%3Dopen I am writing this over the Christmas Break, (the copy dates are a month in advance of publication) and, as our Epetition to the Prime Minister has just *closed*, *...* sportsmansassociation.co.ukhttp://maps.google.com/local_url?q=http://www.sportsmansassociation.co.uk/%3Fp%3D25dq=lynton+close,+wembleyf=qsource=s_qoutput=jshl=engeocode=vps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563s=ANYYN7kQNn5Eq-2wU6NK27oX63h2kwuyfg Off topic, but, what a crazy combination of information google have put together there that I found amusing :) There's still no street view there, but, google's aerial imagery is pretty high resolution... Teleatlas seem to have it fully mapped, including a side road within the area (as seen on google), but perhaps they used the aerial imagery... Navteq, as seen on yahoo didn't seem to want to go near it and it appears made a guess at the angle and length too... d ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging dangerous areas
2009/4/20 D Tucny d...@tucny.com 2009/4/20 Andy Allan gravityst...@gmail.com On Mon, Mar 30, 2009 at 6:33 PM, Matt Amos zerebub...@gmail.com wrote: On Mon, Mar 30, 2009 at 5:31 PM, MP singular...@gmail.com wrote: after the wembley mapping party last year i heard suggestions of a locals=angry tag. maybe we should expand that to include locals=violent or locals=heavily_armed? What happened at the Wembley mapping party? andy and steve independently attempted to map the same road on a council estate but both decided it might not be a wise idea. no violence was done i think, just evil stares. andy actually tagged it locals=angsty, rather than angry, but there is a precedent :-) http://www.openstreetmap.org/browse/way/27794700 I feel like I'm debating a point of order in a student union ( :-) ), but the encampment^Wstreet which Steve8 and I didn't want to map was this one, a short distance away: http://www.openstreetmap.org/browse/way/27693507 Also, if you check on the wiki, the locals=angsty is defined as implying the tag mapper=slightly_lazy and is often used on hot afternoons that bring out the worst in British council estate congregation behaviour. The tag doesn't apply during rain or winter conditions, but applies doubly shortly after football matches... After reading this thread and the comments on the diary post, I decided to see if there was any streetview there now... So, I entered Lynton Close, Wembley into the Google Maps find box and these were the first and third results... Mr T Blairhttp://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=lynton+close,+wembleyvps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563ie=UTF8latlng=42945511,-81211446,8277933314319449699ei=4FnrSaawL5OyiAO7v6nNAQcd=1 - more info »http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=lynton+close,+wembleyvps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563ie=UTF8latlng=42945511,-81211446,8277933314319449699ei=4FnrSaawL5OyiAO7v6nNAQcd=1 10 Downing Crescent, London, ON N6C, Canada - +44 7866 607197 Unverified listing Write a reviewhttps://www.google.com/accounts/ServiceLogin?service=localhl=ennui=1continue=http://maps.google.com/maps%3Ff%3Dq%26source%3Ds_q%26hl%3Den%26geocode%3D%26q%3Dlynton%2Bclose,%2Bwembley%26vps%3D1%26jsv%3D154c%26sll%3D37.0625,-95.677068%26sspn%3D50.424342,79.101563%26ie%3DUTF8%26ei%3D4FnrSaawL5OyiAO7v6nNAQ%26dtab%3D2%26cid%3D42945511,-81211446,8277933314319449699%26iwd%3D1%26iwloc%3DA%26action%3Dopen The Committee will continue to keep all the issues covered by the Sixth Report under *close* review, while also continuing to fulfil its terms of reference by *...* cabinetoffice.gov.ukhttp://maps.google.com/local_url?q=http://archive.cabinetoffice.gov.uk/standards/publications/6th_report/correspondence/neill_blair.htmldq=lynton+close,+wembleyf=qsource=s_qoutput=jshl=engeocode=vps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563s=ANYYN7kCez7hisFRCZIbWnItF_cyjINxcA Gordon Brown'shttp://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=lynton+close,+wembleyvps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563ie=UTF8latlng=42945511,-81211446,1473789639052526619ei=4FnrSaawL5OyiAO7v6nNAQcd=3 - more info »http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=lynton+close,+wembleyvps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563ie=UTF8latlng=42945511,-81211446,1473789639052526619ei=4FnrSaawL5OyiAO7v6nNAQcd=3 10 Downing Crescent, London, ON N6C, Canada - +32 2 298 75 00 Unverified listing Write a reviewhttps://www.google.com/accounts/ServiceLogin?service=localhl=ennui=1continue=http://maps.google.com/maps%3Ff%3Dq%26source%3Ds_q%26hl%3Den%26geocode%3D%26q%3Dlynton%2Bclose,%2Bwembley%26vps%3D1%26jsv%3D154c%26sll%3D37.0625,-95.677068%26sspn%3D50.424342,79.101563%26ie%3DUTF8%26ei%3D4FnrSaawL5OyiAO7v6nNAQ%26dtab%3D2%26cid%3D42945511,-81211446,1473789639052526619%26iwd%3D1%26iwloc%3DA%26action%3Dopen I am writing this over the Christmas Break, (the copy dates are a month in advance of publication) and, as our Epetition to the Prime Minister has just *closed*, *...* sportsmansassociation.co.ukhttp://maps.google.com/local_url?q=http://www.sportsmansassociation.co.uk/%3Fp%3D25dq=lynton+close,+wembleyf=qsource=s_qoutput=jshl=engeocode=vps=1jsv=154csll=37.0625,-95.677068sspn=50.424342,79.101563s=ANYYN7kQNn5Eq-2wU6NK27oX63h2kwuyfg Off topic, but, what a crazy combination of information google have put together there that I found amusing :) There's still no street view there, but, google's aerial imagery is pretty high resolution... Teleatlas seem to have it fully mapped, including a side road within the area (as seen on google), but perhaps they used the aerial imagery... Navteq, as seen on yahoo didn't seem to want to go near it and it appears made a guess at the angle and length too... And some more info...
Re: [OSM-talk] best GPS for trekking
One data point: my Garmin eTrex unit has recently broken the 'zoom in' button on the side - it broke off underneath the rubber bumper and started rattling around inside, so now the map display can be zoomed out but not in. I bought it a few months ago, so will try to get it repaired under warranty. I don't know if competing units have better build quality. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Update: add 'canvec:definition' tag?
Hi all, as im going through the rules.txt file and adding in the 'entity' and 'value' tags, im thinking that adding the tag 'canvec:definition' would help. On some tags its a few lines of text, but it shouldnt go over the max number of characters permitted. Any thoughts? (before i spend uneeded time on it) :-) thanks, Sam -- Twitter @acrosscanada Facebook Page http://www.facebook.com/pages/Victoria-BC/Across-Canada-Trails/36142547420?ref=ts ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] best GPS for trekking
On Sun, Apr 19, 2009 at 3:05 PM, Ed Avis e...@waniasset.com wrote: One data point: my Garmin eTrex unit has recently broken the 'zoom in' button on the side - it broke off underneath the rubber bumper and started rattling around inside, so now the map display can be zoomed out but not in. I bought it a few months ago, so will try to get it repaired under warranty. I don't know if competing units have better build quality. I think the eTrex series is generally pretty robust. I (used to) frequent the geocaching.com boards and saw a lot of complaints about various units, but the eTrex design has been around for a while and is fairly bulletproof. Obviously cases like yours are the exception, but the common complaints about the eTrex construction (when there are any) are the surrounding rubber band separating from the unit (happens more when exposed to temperature extremes) and a loose/disconnected screen ribbon cable (only on older models). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] Manipulating ABS suburb data, and related data..
Hi. I think I'm with Darren on all counts. I think the only thing I'd add is where local knowledge tells you that the ABS data aligns to some previously unmapped feature (e.g. a river) that cannot be made out on Landsat (no Yahoo coverage). There I'm tempted to add the natural feature data to the existing ABS way, and leave the ABS attribution in. I have seen a few places where the ABS suburb boundary seems to exactly match a river or creek outside the Yahoo coverage, and there is no easy way to get a GPS trace for the creek. I'm doing some surveying around Tamworth NSW this weekend, and I was looking forward to uploading my traces tonight, but of course the OSM database is being upgraded! - Ben. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Manipulating ABS suburb data, and related data..
On Sun, 19 Apr 2009 19:47:04 +1000 Ben Kelley ben.kel...@gmail.com wrote: Hi. I think I'm with Darren on all counts. I think the only thing I'd add is where local knowledge tells you that the ABS data aligns to some previously unmapped feature (e.g. a river) that cannot be made out on Landsat (no Yahoo coverage). There I'm tempted to add the natural feature data to the existing ABS way, and leave the ABS attribution in. I have seen a few places where the ABS suburb boundary seems to exactly match a river or creek outside the Yahoo coverage, and there is no easy way to get a GPS trace for the creek. Oh yeah, I've done that for a couple of things too now that you mention it :) And yes I've left the attribution tag in for sure. I'm doing some surveying around Tamworth NSW this weekend, and I was looking forward to uploading my traces tonight, but of course the OSM database is being upgraded! Know that feeling, I have several days of Easter holiday traces to go in also. *twiddles*thumbs* -- =b ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Manipulating ABS suburb data, and related data..
On Sun, 19 Apr 2009, Darrin Smith wrote: Know that feeling, I have several days of Easter holiday traces to go in also. *twiddles*thumbs* we were just catching up from December in our house, now the days are shorter, and have stuff waiting for upload more thumb twiddling ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Straßenliste für EMDEN
On Sat, 18 Apr 2009 20:26:13 +0200 Jan Tappenbeck o...@tappenbeck.net wrote: Moin so, auch die Emdener haben jetzt eine Straßenliste: Tipp: Wenn Du mal da bist, sag lieber Emder :-) http://wiki.openstreetmap.org/wiki/Emden Danke an SvenA. Dito. Emden und weite Teile Ostfrieslands entwickeln sich OSM-technisch eher langsam. Hat jemand Interesse an einer OSM-Ostfriesland Mailingliste? Gruß, Daniel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenliste für EMDEN
Daniel van Gerpen schrieb: Emden und weite Teile Ostfrieslands entwickeln sich OSM-technisch eher langsam. Hat jemand Interesse an einer OSM-Ostfriesland Mailingliste? Dort wo sich nichts tut wird es auch nur wenige Mapper geben. Die Chance, hier jemanden zu finden wird gering sein. Schau Dir doch mal die Leute an die dort schon etwas gemacht haben und maile die an. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garminkarte für ganz Deutschland
Hallo Mitmapper, ich habe die Downzeit der API sinnvoll genutzt und es endlich geschafft eine halbwegs vernünftige Garmin-karte für ganz Deutschland zu produzieren. Die Karte könnt ihr hier runterladen: http://www.juergen-frank.de/osm/gmapsupps/germany/gmapsupp.img.tar.bz2 Die Karte ist routingfähig (auch über Kachelgrenzen), besitzt abschaltbare Höhenlinien, FIXMEs, Openstreetbugs und Adressen. Es sind für die verschiedenen Layer mehrere Typfiles eingebaut. Wie ich das alles genau gemacht habe, werde ich noch dokumentieren, hatte bisher aber keine Zeit dazu. Alles was ich weiß, werde ich hier dazu nach und nach einpflegen: http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map Die aktuelle Dokumentation stimmt teilweise schon nicht mehr! Testet sie aus und gebt mir Rückmeldung. Die zugehörigen Style- und Typfiles werde ich später noch hochladen. Wenn Deutschland so halbwegs gut ankommt, könnte ich mich auch mal um Europa kümmern, in der Hoffnung das hinzubekommen. (der tilesplitter teilt Deutschland zur Zeit in 34 Kacheln - 256 sind maximal möglich, also ist eventuell noch etwas Spielraum für einige andere Länder... - muss aber zunächst testen, wie sich das mit den Layern verträgt!) Viel Spaß beim ausprobieren und Grüße! Christoph PS: Ich weiß, dass einige Leute die Karte so nicht nutzen können, weil sie keinen Massenspeichermodus besitzen und sendmap beim hochladen die Typfiles verkackt. Lösung wäre alle Kacheln und Typfiles einzeln anzubieten, die dann der User mit sendmap beim aufs Gerät laden zusammenklebt. Wäre für mich zur Zeit aber doppelter Traffic! Wieviele Leute betrifft das? Kennt jemand ne andere Lösung? Soll ich die Kacheln immer einzeln hochladen? (Der Vorteil wäre, dass man sich aussuchen könnte, welche Layer man so braucht. Außerdem könnte ich sowas wie die Openstreetbugs regelmäßiger aktualisieren. Allerdings müssten dann alle die Kacheln selber zusammenkleben, was an sich kein großes Ding ist, aber schon einigen Ärger verursachen kann) signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenliste für EMDEN
Daniel van Gerpen schrieb: Emden und weite Teile Ostfrieslands entwickeln sich OSM-technisch eher langsam. Hat jemand Interesse an einer OSM-Ostfriesland Mailingliste? Ich vermute, dass wenig bringen wird. Meine Empfehlung: Die Wiki-Seite aktuell halten und bei Wikipedianern, bei LUGlern und bei Geocachern neue Mitstreiter keilen. (Aber zugegenermaßen sieht es auch bei denen jeweils vergleichsweise strukturschwach in der Gegend aus.) Was das Mappen anbelangt: Wenn ich die Garmin-Topo sehe, dann glaube ich, dass OSM im Bereich der Siel- und Wasserachten auch mittelfristig keine Chance hat, schöner auszuschauen. Denn die Entwässerungsverbände haben wirklich jede Graben ab ca. 1m Breite in der Topo. Folglich sind da ganze Landstriche eher blau als schwarz gemustert: Beispiel: http://www.addicks.net/albums/osm/Flachland_OSMvsTOPO25.png -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] routing über highway=path
also in einem Wohngebiet ist die Straße die alles verbindet (also Verbindungscharakter hat) eine tertiary. unclassified gibts innerorts meiner Meinung nach nicht (es sei denn es hat außerörtlichen Charakter ohne Verbindungscharakter).-- Mario -Original Message- Date: Sat, 18 Apr 2009 19:56:15 +0200 Subject: Re: [Talk-de] routing über highway=path From: Martin Koppenhoefer dieterdre...@gmail.com To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Am 17. April 2009 17:42 schrieb Mario Salvini salv...@t-online.de: unclassified hat doch gerade eher keinen Verbindungscharakter. ja eher nur einen untergeordneten (ist die niedrigste Stufe von Verbindungsstraßen). Ich persönlich benutze unclassified für belanglose Straße irgendwo außerorts (denn innerorts wäre es eine residential. innerorts sind es m.E. nur dann residentials, wenn sie nicht mal den Anschein von Verbindungscharakter haben. Alles, was selbst ein paar (kleinere) Straßen verbindet, ist bei mir unclassified. Residential benutze ich für Straßen, wo ausser den Anwohnern keiner zu fahren braucht (hat nichts mit dürfen zu tun), und wo es zudem diese Wohnbebauung überhaupt gibt. Wenn es sich um Straßen handelt, wo zwar Leute Wohnen, die aber auch sonst genutzt werden müssen (sollten), dann sind es bei mir mind. unclassified (oder gleich was höheres). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OWL Trifft sich / 21.4. 19:00
Hi, OSM-OWL trifft sich erneut - Am 21.4. 19:00 in Bad Salzuflen im Event. Hier entlang: http://wiki.openstreetmap.org/wiki/OWL-Treffen#Das_5._Treffen_.2F_2009-04-21 Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klassifizierung von Fußwegen
Garry wrote: Gerrit Lammert schrieb: Ich weiß nicht, ob ich Dich verstehe. Eine Plattform (also in diesem Fall ein Bahnsteig), wo eine RegioTram hält bekommt ein services=light_train (oder wo man RegioTram halt einsortiert). Das dort auch ein ICE vorbeifährt oder ein Flugzeug drüberfliegt spielt doch keine Rolle!? Wenn der ICE dort auch hält bekommt der Bahnsteig ein services=light_rail;rail. Und wenn auf der anderen Seite ein Bus hält, bekommt er services=light_rail;rail;Bus to service heiss bedienen. Alles was von dort bedient wird, kommt als Wert in services Halt alles, wo rein man von dort aus einsteigen kann. Steht doch so im Proposal!? Was nicht daraus hervorgeht ist ob im Bedarfsfall auch was grösseres als light_rail halten kann... Das ist auch nicht die Aufgabe. Wenn an der vorbeiführenden Bahntrasse eine ICE-Linie eingetragen ist, wird das doch impliziert. Ich trag doch auch nicht an Bushaltestellen ein, dass dort auch normale Autos oder Taxen mal halten oder ein Notarzt-Hubschrauber dort mal landen könnte. Manche Leute suchen auch Probleme... Gerrit PS: Nach der Logik müsste man hier leider jeden straßenbegleitenden Radweg als Parkplatz eintragen. :( ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingprobleme visualisieren?
On Sat, Apr 18, 2009 at 02:16:26AM +0200, Marcus Wolschon wrote: - guter erfassungsgrad braucht derzeit 0.8sek auf meinem notebook. Ich habe Deutschland von gestern als Datenbasis. Also 0,8sec gegen geratene 1sec halte ich jetzt für nicht soo viel besser. Zumal es nicht direkt aus der .osm arbeiten kann sonder erstmal eine konvertierte Karte braucht. Das konvertieren mache ich einmal am tag und das braucht 2-3 Minuten. Die 0.8sek haben noch eine menge optimierungspotential meiner meinung nach. Denn das ist der klumpatsch mit karte oeffnen indexe lese etc fuer nur eine route. Das eigentlich berechnen ist ja schneller. Kleinen batch job im C code implementiert der die karte nur einmal oeffnet und schon duerfte das ganze nochmal gewinnen. Stichwort: Working set und cache size. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Christoph Wagner freemaps@googlemail.com writes: [...] PS: Ich weiß, dass einige Leute die Karte so nicht nutzen können, weil sie keinen Massenspeichermodus besitzen und sendmap beim hochladen die Typfiles verkackt. Lösung wäre alle Kacheln und Typfiles einzeln anzubieten, die dann der User mit sendmap beim aufs Gerät laden zusammenklebt. Wäre für mich zur Zeit aber doppelter Traffic! Wieviele Leute betrifft das? Ich bin wegen GPSMAP 76S auf sendmap angewiesen, kann aber auch nichts mit routingfähigen Karten machen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tool gesucht für die Suche nach näc hster
Hallo Jan, wenn Du es nur selten brauchst sollte man es schaffen so etwas mit JOSM hinzubekommen, zumindest wenn die x m nicht ganz so genau sind. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Routingoptmierung
Hallo, - Kreisverkehre werden falsch herum durchfahren wenn der Weg so kürzer ist. Lösungsansatz: Den Kreisverkehr grundsätzlich als Einbahnstrasse markieren? Das sollte doch wohl sebstverständlich sein. Woher soll das ein Router sonst wissen? - Autobahnauffahrten lassen einem im unklaren in welche Richtung man auf welche Autobahn fährt. Das ist aber eher ein Problem des Routers, denn er könnte es ja aus den Daten ermitteln. Hat eigentlich schonmal jemand mit Garmin kontakt gehabt, vieleicht könnte da ja kooperiert werden. Natürlich mit offenen Standards,... - Rerouting auf residential lässt sehr lange auf sich warten (wenn man vom vorgeschlagenen Weg abweicht) Und das hängt vom Straßentyp ab? Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Artwork-Team - StyleGuide
Zitat malenki: Michael Buege schrieb: OSM und Google dealen vielleicht mit dem selben Stoff, aber der unsrige ist Bio, ungefiltert, unverschnitten und umsonst. Konkurrenzlos. Anmerkung: umsonst verwende ich, wenn etwas wirklich für die Katz, sinnlos, nutzlos ist. Bekomme ich etwas Sinnvolles geschenkt, ist das gratis, kostenlos oder kostenfrei. Du hast recht. Es muesste auch mit dem _gleichen_ Stoff heissen, denn der selbe ist es nicht. Ich solle wirklich noch mal lesen, was ich geschrieben habe, bevor ich es abschicke. ;-) -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Hallo, Sebastian Niehaus schrieb: Ich bin wegen GPSMAP 76S auf sendmap angewiesen, kann aber auch nichts mit routingfähigen Karten machen. Na dann empfiehlt sich vielleicht für Dich eher meine Karte? -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
hi, super sache. eins noch aus neugier. ziehst du die openstreetbugs selber oder nimmst du meine daten? tnx gerhard gary68 On Sun, 2009-04-19 at 09:57 +0200, Christoph Wagner wrote: Hallo Mitmapper, ich habe die Downzeit der API sinnvoll genutzt und es endlich geschafft eine halbwegs vernünftige Garmin-karte für ganz Deutschland zu produzieren. Die Karte könnt ihr hier runterladen: http://www.juergen-frank.de/osm/gmapsupps/germany/gmapsupp.img.tar.bz2 Die Karte ist routingfähig (auch über Kachelgrenzen), besitzt abschaltbare Höhenlinien, FIXMEs, Openstreetbugs und Adressen. Es sind für die verschiedenen Layer mehrere Typfiles eingebaut. Wie ich das alles genau gemacht habe, werde ich noch dokumentieren, hatte bisher aber keine Zeit dazu. Alles was ich weiß, werde ich hier dazu nach und nach einpflegen: http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map Die aktuelle Dokumentation stimmt teilweise schon nicht mehr! Testet sie aus und gebt mir Rückmeldung. Die zugehörigen Style- und Typfiles werde ich später noch hochladen. Wenn Deutschland so halbwegs gut ankommt, könnte ich mich auch mal um Europa kümmern, in der Hoffnung das hinzubekommen. (der tilesplitter teilt Deutschland zur Zeit in 34 Kacheln - 256 sind maximal möglich, also ist eventuell noch etwas Spielraum für einige andere Länder... - muss aber zunächst testen, wie sich das mit den Layern verträgt!) Viel Spaß beim ausprobieren und Grüße! Christoph PS: Ich weiß, dass einige Leute die Karte so nicht nutzen können, weil sie keinen Massenspeichermodus besitzen und sendmap beim hochladen die Typfiles verkackt. Lösung wäre alle Kacheln und Typfiles einzeln anzubieten, die dann der User mit sendmap beim aufs Gerät laden zusammenklebt. Wäre für mich zur Zeit aber doppelter Traffic! Wieviele Leute betrifft das? Kennt jemand ne andere Lösung? Soll ich die Kacheln immer einzeln hochladen? (Der Vorteil wäre, dass man sich aussuchen könnte, welche Layer man so braucht. Außerdem könnte ich sowas wie die Openstreetbugs regelmäßiger aktualisieren. Allerdings müssten dann alle die Kacheln selber zusammenkleben, was an sich kein großes Ding ist, aber schon einigen Ärger verursachen kann) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenliste für EMDEN
Moin Daniel van Gerpen schrieb: http://wiki.openstreetmap.org/wiki/Emden Danke an SvenA. Dito. Dem schließe ich mich an. Emden und weite Teile Ostfrieslands entwickeln sich OSM-technisch eher langsam. Das stimmt leider, auch wenn immer wieder mal ein neuer Mapper auftaucht und ein paar Straßen macht (und dann i.d.R. auch wieder verschwindet). Insgesamt ist die Entwicklung sehr langsam. Hat jemand Interesse an einer OSM-Ostfriesland Mailingliste? Halte ich für eine Idee, der man eine Chance geben sollte. Ich wär auf jeden Fall dabei. Grüße aus Wittmund, Latze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Am 19.04.2009 um 12:54 schrieb Gary68: hi, super sache. eins noch aus neugier. ziehst du die openstreetbugs selber oder nimmst du meine daten? Super Sache. Ich habe diese routingfähige Karte gleich auf mein Garmin Etrex Vista HCx geladen. Das Routing funktioniert überwiegend ordentlich, allerdings habe ich auch einzelne Routen über Fusswege festgestellt, obwohl als Routingoption Auto/Motorrad gewählt wurde. Da muss wohl noch ein bisschen gefeilt werden... Gruß Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Christoph Wagner freemaps@googlemail.com wrote: Die Karte ist routingfähig (auch über Kachelgrenzen), besitzt abschaltbare Höhenlinien Ich nehme an, dass die alle in einer separaten img-Datei drinstecken. Kann man die für eigene Experimente mit mkgmap irgendwo runterladen? Sven -- If you can spend five minutes on the Internet and do not run Linux, you're a genius. (Dirk Hohndel) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Das Problem oder besser der Wert besteht in kulturellen Eigenheiten, die überraschend oft mit der Sprache einher gehen. Wenn Grönländer 50 verschiedene Begriffe für Scheeneweiß verwenden und Deutsche nur einen. Guckst Du, gell? Daher ist es bei historischen, aus Zeiten der noch nicht so dichten und zeitparallelen Vernetzung/Globalisierung berechtigt besser die eigene Sprache zu verwenden, als Begriffe die nicht zutreffend sind zu entlehnen. Wie so oft schon geschrieben kann alles für vereinfachte Darstellungen homologisiert werden, andererseits müßte hier jeder Experte auf jedem Gebiet sein. Das wär nicht schön für die Qualität des Projekts. Gruß, Stephan. Hi! Michael Buchberger schrieb: * castle_type=castle_res für Schloss (res für residential, dient hauptsächlich dem Wohnen) * castle_type=castle_fort für Burg (fort für fortified, befestigt) * castle_type=castle anstatt Schloss;Burg * castle_type=fort für Festung Ich kenne die Vorgeschichte jetzt nicht, aber so für sich betrachtet, finde ich beide Ideen nicht besonders. castle_res und castle_fort sind unverständlich kryptisch, außerdem ist das castle eine Wiederholung aus dem key. Ich sehe jetzt auch keinen Sinn darin, deutsche Begriffe als Values zu verwenden, wenn sonst alles auf Englisch abgefaßt ist und ich kann auch das Übersetzungsproblem nicht nachvollziehen. Wenn man den Begriff halbwegs trifft und im Wiki gut definiert, sollte das ausreichen. Burg = castle Schloß = palace oder manor Festung = fortress Wo ist das Problem? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Artwork-Team - StyleGuide
Michael Buege schrieb: Du hast recht. Es muesste auch mit dem _gleichen_ Stoff heissen [...] Das habe ich wiederum übersehen. Umsonst war wohl mein Aufmerksamkeitsmagnet. ;) Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Stephan Schildberg schrieb: Das Problem oder besser der Wert besteht in kulturellen Eigenheiten, die überraschend oft mit der Sprache einher gehen. Wenn Grönländer 50 verschiedene Begriffe für Scheeneweiß verwenden und Deutsche nur einen. Guckst Du, gell? Daher ist es bei historischen, aus Zeiten der noch nicht so dichten und zeitparallelen Vernetzung/Globalisierung berechtigt besser die eigene Sprache zu verwenden, als Begriffe die nicht zutreffend sind zu entlehnen. Wie so oft schon geschrieben kann alles für vereinfachte Darstellungen homologisiert werden, andererseits müßte hier jeder Experte auf jedem Gebiet sein. Das wär nicht schön für die Qualität des Projekts. Gruß, Stephan. Das Problem liegt hier - wie so oft - eigentlich woanders. Wie nop ja schon geschrieben hatte, gibt es auch im englischen durchaus gängige Begriffe für diese verschiedene Arten von Gebäuden. Das historic=castle stammt aber noch aus einer Zeit, wo es soviele Unklarheiten an allen möglichen Stellen gab, daß man froh war einen Begriff zu haben der erstmal irgendwie gepaßt hat und hat den halt genommen. Da wir hier in Deutschland halt *nur* spezielle Begriffe für Burg, Schloß und Festung haben, fällt uns das hier halt eher auf (bzw. stört uns eher). Nehmt doch: historic=palace historic=fortress Die Probleme mit der aktuellen Unterscheidung zu historic=castle werden sich dann im Laufe der Zeit schon legen. Übrigens: Der Zustand der Burg (bewohnt, unbewohnt, Ruine, abgegangen, ...) sollte nicht mit in den gleichen Tag rein, das kann aus meiner Sicht nicht klappen und verwirrt nur. Gruß, ULFL Hi! Michael Buchberger schrieb: * castle_type=castle_res für Schloss (res für residential, dient hauptsächlich dem Wohnen) * castle_type=castle_fort für Burg (fort für fortified, befestigt) * castle_type=castle anstatt Schloss;Burg * castle_type=fort für Festung Ich kenne die Vorgeschichte jetzt nicht, aber so für sich betrachtet, finde ich beide Ideen nicht besonders. castle_res und castle_fort sind unverständlich kryptisch, außerdem ist das castle eine Wiederholung aus dem key. Ich sehe jetzt auch keinen Sinn darin, deutsche Begriffe als Values zu verwenden, wenn sonst alles auf Englisch abgefaßt ist und ich kann auch das Übersetzungsproblem nicht nachvollziehen. Wenn man den Begriff halbwegs trifft und im Wiki gut definiert, sollte das ausreichen. Burg = castle Schloß = palace oder manor Festung = fortress Wo ist das Problem? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Carsten Schwede computerte...@gmx.de writes: [...] Sebastian Niehaus schrieb: Ich bin wegen GPSMAP 76S auf sendmap angewiesen, kann aber auch nichts mit routingfähigen Karten machen. Na dann empfiehlt sich vielleicht für Dich eher meine Karte? Exakt, und die benutze ich schon schon seit längerem. Mal wieder Gelegenheit für ein ganz großes Danke. Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [erledigt] Re: Wikimedia-Bilder ins OSM-Wiki einbetten
Moin Johann, malenki schrieb: Man will sehen, ob Fehler auftreten und Proteste zu hören sind. Funktioniert. mh, werden Änderungen auf der commons-Bildbeschreibungsseite, die erst /nach/ der Einbindung ins OSM-Wiki stattfinden, irgendwann übernommen? Oder ist die Einbindung statisch? Wir bekommen sonst möglicherweise Probleme mit inkompatiblen Lizenzen. Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Das Problem oder besser der Wert besteht in kulturellen Eigenheiten, die überraschend oft mit der Sprache einher gehen. Wenn Grönländer 50 verschiedene Begriffe für Scheeneweiß verwenden und Deutsche nur einen. Guckst Du, gell? Ist zwar OT, sollte man aber trotzdem so nicht stehen lassen: http://www.iaas.uni-bremen.de/sprachblog/2007/01/29/schneeschmelze/ -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Nop schrieb: Michael Buchberger schrieb: * castle_type=castle_res für Schloss (res für residential, dient hauptsächlich dem Wohnen) * castle_type=castle_fort für Burg (fort für fortified, befestigt) * castle_type=castle anstatt Schloss;Burg * castle_type=fort für Festung Ich kenne die Vorgeschichte jetzt nicht, aber so für sich betrachtet, finde ich beide Ideen nicht besonders. castle_res und castle_fort sind unverständlich kryptisch, außerdem ist das castle eine Wiederholung aus dem key. Mir fiel nichts Passenderes ein für die Übersetzung ins Englische. Ich sehe jetzt auch keinen Sinn darin, deutsche Begriffe als Values zu verwenden, wenn sonst alles auf Englisch abgefaßt ist Ich sehe aber auch kein Problem darin, denn und ich kann auch das Übersetzungsproblem nicht nachvollziehen. Wenn man den Begriff halbwegs trifft und im Wiki gut definiert, sollte das ausreichen. Das träfe auf deutschsprachige values ebenfalls zu. Burg = castle Schloß = palace oder manor Die deutschen Begriffe Schloss und Palast könnte man hier synonym verwenden, so dass Schloss^=Palast=palace zuträfe. Manor passt besser auf Rittergüter oder kleine Landsitze, die nicht viel mit einem Schloss gemein haben Festung = fortress Wo ist das Problem? Ja, jetzt, wo du es mal gut formulierst... :) Was wird aus castle_type=burg;schloss? Meinungen zu Obigem? Spielt da nciht auch noch das Chaos um das Tag ruin mit rein? Die einen Taggen z.B. als Castle, ruined = yes, die anderen als historic=ruin. Damit kann man leider Burgen-, Kirchen-, Industrie- und 3.Reichruinen nicht voneinander unterscheiden. Gibt's dazu schon weiterführende Gedanken? In http://wiki.openstreetmap.org/wiki/Key:historic steht zu historic=ruins: Remains of a castle or alike, usage was abandoned Sollte man noch umformulieren und die Alternative ruins=yes vorschlagen. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Am 19. April 2009 13:55 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Da wir hier in Deutschland halt *nur* spezielle Begriffe für Burg, Schloß und Festung haben, fällt uns das hier halt eher auf (bzw. stört uns eher). wir haben halt Burgen, die es woanders so gar nicht gibt (wobei ich nicht sage, dass der Verbreitungsraum von Burgen mit den heutigen deutschen Staatsgebiet oder Sprachgebiet deckungsgleich ist). Nehmt doch: historic=palace historic=fortress ab wann ist denn ein Palast historic? Gehört da z.B. ein Palast von Saddam Hussein oder Ceaucescu dazu? Einer von Anfang des 20. Jh.? Einer von Ende des 18. Jh.? Einer spätrömischer? Ein babylonischer? Einer von Kim Jong Il? Ich finde historic im Grunde problematisch, weil es alles sein kann von 10 Jahre alt aber Machtverhältnisse inzwischen geändert bis zum akkadischen Palast aus dem 2. Jahrtausend v.Chr. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenliste für EMDEN
Am 19. April 2009 10:01 schrieb Johann H. Addicks addi...@gmx.net: Was das Mappen anbelangt: Wenn ich die Garmin-Topo sehe, dann glaube ich, dass OSM im Bereich der Siel- und Wasserachten auch mittelfristig keine Chance hat, schöner auszuschauen. Denn die Entwässerungsverbände haben wirklich jede Graben ab ca. 1m Breite in der Topo. Folglich sind da ganze Landstriche eher blau als schwarz gemustert: Beispiel: http://www.addicks.net/albums/osm/Flachland_OSMvsTOPO25.png interessant, und durchaus ja auch sinnvoll, muss man für Gräben über 1 m Breite doch durchaus sportlich sein, um diese nicht als Hindernis wahrzunehmen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
malenki schrieb: Manor passt besser auf Rittergüter oder kleine Landsitze, die nicht viel mit einem Schloss gemein haben Die westfälischen Wasserschlösser würde ich als Schloss, aber nicht als Palast bezeichnen. Als Anschauung: http://de.wikipedia.org/wiki/Dortmund/#Burgen_und_Schl.C3.B6sser Die Übergänge sind nicht nur zwischen den sprachlichen Kulturen verschieden, sondern auch innerhalb Deutschlands und Österreichs. Abhängig davon, ob es einen mächtigen Regenten gab oder eher einen starken Landadel. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Martin Koppenhoefer schrieb: Am 19. April 2009 13:55 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Da wir hier in Deutschland halt *nur* spezielle Begriffe für Burg, Schloß und Festung haben, fällt uns das hier halt eher auf (bzw. stört uns eher). wir haben halt Burgen, die es woanders so gar nicht gibt (wobei ich nicht sage, dass der Verbreitungsraum von Burgen mit den heutigen deutschen Staatsgebiet oder Sprachgebiet deckungsgleich ist). Nehmt doch: historic=palace historic=fortress ab wann ist denn ein Palast historic? Gehört da z.B. ein Palast von Saddam Hussein oder Ceaucescu dazu? Einer von Anfang des 20. Jh.? Einer von Ende des 18. Jh.? Einer spätrömischer? Ein babylonischer? Einer von Kim Jong Il? Ich finde historic im Grunde problematisch, weil es alles sein kann von 10 Jahre alt aber Machtverhältnisse inzwischen geändert bis zum akkadischen Palast aus dem 2. Jahrtausend v.Chr. ++ Als historisch bezeichnet doch nur die politisch führende Meinung der Gegenwart. Sind der Palast der Queen in London und Windsor Castle historisch? Weder der Baustil noch die komplett abgeschlossene Epoche (welche immer aus der Gegenwart und je nach Betrachter interpretiert wird) liegt hier vor. Was ist mit Kunstburgen, Kunstschlössern (Berliner Stadtschloß, Neuschwanstein um ein paar bekanntere zu nennen) ? Historisch ist alles von nun an oder? Gruß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Christoph Wagner schrieb: Die Karte ist routingfähig (auch über Kachelgrenzen), besitzt abschaltbare Höhenlinien, FIXMEs, Openstreetbugs und Adressen. Wie bekommt man denn die Höhenlinien angeschaltet? OSB, Fixmeed, Adrressen(sic!) und Fixmes finde ich in der Auswahl. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Routingoptmierung
Tobias Knerr schrieb: Meiner unwesentlichen Meinung nach sollten Anwendungen versuchen, Implikationen unterstützen, wie sie etwa im Wiki auch genannt werden. Wenn ich es richtig verstanden haben, dann sprechen wir in diesem konkreten Fall über ein Fehlrouting, welches dadurch möglich wurde, dass ein Kreisverkehr a) Nicht als Kreisverkehr getagt war und gleichzeitig b) der Oneway falschherum eingetragen war. Ich glaube nicht, dass in so einem Szenario den Router eine Schuld trifft. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gräben in der LVA-Top25 (was: Stra ßenliste für EMDEN)
Martin Koppenhoefer schrieb: interessant, und durchaus ja auch sinnvoll, muss man für Gräben über 1 m Breite doch durchaus sportlich sein, um diese nicht als Hindernis wahrzunehmen. Ich bin schon öfter über solche in der Topo eingezeichnte Gräben gehüpft... mit Anlauf... Nein, ich bin nicht sonderlich sportlich, sondern will damit sagen: Diese (gefühlte) 1m-Grenze liegt wirklich so niedrig. Andererseits: Die Entwässerungsverbände bekommen Unmengen von Geld von den Landeigentümern. Von daher liegt ihnen wohl daran, zu zeigen, wieviel Millionen Grabenkilometer sie auf Pegel halten. Schade nur, dass diese Dokumentation nicht gemeinfrei abgegeben wird. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Routingoptmierung
Johann H. Addicks schrieb: Tobias Knerr schrieb: Meiner unwesentlichen Meinung nach sollten Anwendungen versuchen, Implikationen unterstützen, wie sie etwa im Wiki auch genannt werden. Wenn ich es richtig verstanden haben, dann sprechen wir in diesem konkreten Fall über ein Fehlrouting, welches dadurch möglich wurde, dass ein Kreisverkehr a) Nicht als Kreisverkehr getagt war und gleichzeitig b) der Oneway falschherum eingetragen war. Ich glaube nicht, dass in so einem Szenario den Router eine Schuld trifft. Natürlich trifft den Router in einem solchen Fall keine Schuld. Das ist ein Fehler in den Daten, der auch dort (und nur dort) korrigiert werden sollte. Meine Aussage bezog sich auf die recht pauschale und nicht offensichtlich auf den vorliegenden Einzelfall bezogene Aussage, es solle doch wohl selbstverständlich sein, einen Kreisverkehr grundsätzlich (zusätzlich) als Einbahnstraße zu markieren. So hab ich jedenfalls das hier verstanden: Dimitri Junker schrieb: - Kreisverkehre werden falsch herum durchfahren wenn der Weg so kürzer ist. Lösungsansatz: Den Kreisverkehr grundsätzlich als Einbahnstrasse markieren? Das sollte doch wohl sebstverständlich sein. Woher soll das ein Router sonst wissen? Kann da natürlich auch durchaus was falsch interpretiert haben. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernmapping Relationen (Karlsruher Schema)
Hallo! marcus.wolsc...@googlemail.com schrieb: On Wed, 15 Apr 2009 09:04:56 + (UTC), Gernot Hillier ger...@hillier.de wrote: Seit einiger Zeit mappe ich Hausnummern nach dem auf http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema beschriebenen Vorgehen. Klappt auch alles soweit ganz nett, mir stellen sich aber ein paar grundlegende Fragen: * Ist jetzt das Vorgehen mit addr:street oder die associatedStreet-Relation vorzuziehen oder beides? Momentan mache ich beides, als Informatiker würde ich aber am liebsten *nur* die Relation verwenden, um doppelte (und damit potenziell widersprüchliche) Daten zu vermeiden. Wie haltet Ihr das? Die Idee damals im Treffen war, dass die Relation einfach und eindeutig auszuwerten ist und vorgezogen wird. Da man das aber den Mappern nicht als einziger Weg zuzumuten war, wurde als Alternative das addr:street aufgenommen. Also: * eines von beiden Reicht * Relation hat im Zweifelsfall Vorrang * addr:street ist einfacher für Mapper aber aufwendiger und weniger eindeutig * associatedStreet-Relation ist einfacher für Computer Ok, habe mir die Freiheit genommen, die deutsche und engl. Wiki-Seite entsprechend zu erweitern. -- Gernot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Aktion im Sommer im LK Schwäb isch Hall
Hallo. Bernd Wurst schrieb: Soweit ich sehe, ist in der Stadt SHA doch schon in ein paar Schüben das meiste an Straßen im Stadtgebiet erfasst worden. Kennt du lord-of-linux näher? Er hat einiges gemapped. Lord of Linux ist besagter Kollege ;). Ich wüsste nicht, was jetzt ein Busunternehmer davon haben sollte, dir bzw. euch irgendwas umsonst zu geben. Fragen kostet bekanntlich nichts. Neben dem Ratschlag, sich mal intensiv mit den Leuten von Bohmte in Verbindung zu setzen würde ich noch sagen: Holt die Stadtverwaltung ins Boot. Wenn die mitmachen und das entsprechend bewerben können, bekommst du automatisch viel mehr Leute die die Publicity mit weiterer Unterstützung mit-nutzen wollen. Wer oder was ist denn Bohmte? Ansonsten eine sehr gute Idee. Wir hatten sowieso vor, vorher mal mit der Lokalzeitung zu reden und auch im stadteigenen Radio etwas Werbung zu machen. Wenn die nicht mit macht, wären Vereine (Albverein?), VHS oder dergleichen auch eine interessante Zielgruppe. Bei der VHS haben wir letztes Jahr schon nach Räumlichkeiten gefragt. Die waren allerdings schon ausgebucht und hatten wenig Plätze wegen einem Brandschutzausbau in der Sommerzeit. Aber sonst eine gute Idee. Wenn ich SHA aus OSM mit einschlägigen Luftbildern vergleiche würde ich sagen, im Stadtgebiet ist es uninteressant zu mappen. Es fehlen zwar sicherlich noch etliche Meta-Informationen (Geschwindigkeitsbegrenzungen, POIs) aber der entscheidende Funken Motivation entsteht doch beim Entdecken von Neuland. Damit begeistert man am meisten Leute. Das stimmt. Wir wollten auch nicht direkt in der Stadt mappen sondern eher außerhalb. Deshalb auch die Sache mit den Bussen. Irgendwie muss man die Leute ja in die Dörfer bekommen. Eine weitere Idee wären natürlich Fahrgemeinschaften oder das Rad. Ihr solltet also eher die ländlichen Ortschaften ins Visier nehmen oder (das wäre mein spontaner Favorit) das Problemkind Crailsheim. Crailsheim ist momentan noch echt dürftig. Da kannst du ohne Busunternehmen einfach von einem zentralen Punkt loslaufen und jedes Team geht in ne andere Richtung. Und jeder findet ne Menge Neuland. Das stimmt leider und ist zum Großteil auch meine Schuld, denn ich bin aus Crailsheim. Im Ort SHA selbst ist es, wie gesagt, eigentlich gar nicht so schlecht. Gibt es in SHA oder in Crailsheim eigentlich eine aktive Linux-User-Group oder eine CCC-Regionalgruppe? Die sind thematisch nah genug dran, dass sowas in der Regel auf Interesse stößt. In Crailsheim ist mir definitiv nichts derartiges bekannt. Und in Hall habe ich auch noch von nichts gehört, aber ich werde mich dahingehend nochmal informieren. Danke schonmal für diese Starthilfe, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status-Update: Adress-Suche bei Garmin-Karten
Hi! Bernd Wurst schrieb: Hallo. Am Mittwoch 15 April 2009 08:21:11 schrieb Gernot Hillier: Über landuse- oder place-Polygone funktioniert nicht und Orts-boundaries haben wir bisher sehr wenige drin. Warum soll es über Place-Polygone nicht funktionieren? Was genau stellt denn ein place-Polygon dar? Wenn wir von einer Flächengemeinde reden, dann gibt es da viele kleine hamlets und ein paar villages und alle haben den selben Gemeindenamen (der physisch gar nicht als Ort existiert). Die Straßen in den hamlets sollten gefunden werden, wenn man als Ort den Gemeindenamen angibt. Und wenn man den Namen des nächsten village angibt. Was Du hier beschreibst, sind generelle Probleme der Zuordnung Straße-Ort. Ich sehe nicht, was das damit zu tun hat, wie man denn diese Zuordnung trifft. Und nebenbei: dieses Problem haben auch die kommerz. Navi-Hersteller für hamlets noch nicht wirklich gelöst. Bin deswegen schonmal bei einer gleichnamigen Straße in einem Örtchen 7 km neben meinem eigentlichen Zielort gelandet (Medion GoPal 4.x mit Karten von Q4/06). Weil leider die Straße unter der mir gegebenen Post-Adresse nicht auffindbar war. Nur ich denke, dass das Hauptanwendungsgebiet einer Adresssuche das Finden von Straßen in großen Städten ist. Und hier ist für mich die Antwort einfach... Ich bin mir selbst nicht sicher, wie man ein place-Polygon zeichnen sollte, daher lasse ich es momentan immer weg. Wenn man nur die bebaute Fläche umrandet, sperrt man eventuell ausgelagerte Straßen aus, Vororte, Aussiedlerhöfe, ... Wenn man die gesamte Gemarkung umrandet, hat man gegenüber dem boundary- Polygon nichts wesentliches gewonnen. ... ich gehe von den existierenden Ortsschildern aus und nehme die als Grenzen für mein place-Polygon. Der Rest ergiebt sich meist relativ klar aus der Bebauung. So war's zumindest für Landshut und ein paar umliegende Gemeinden. Mein persönlicher Favorite wäre ja, dass man Straßen für die Adress-Suche komplett ignoriert und nur die verfügbaren Straßen aus den Hausnummern des KA- Schema aggregiert. Damit bekommt man auch alle Straßen die eine Adresse haben. Nachteile sind klar: - Straßen ohne Baugrundstücke (== ohne Hausnummer) kann man dann nicht finden. - Man braucht bei jeder Straße mind. eine eingetragene Hausnummer. Also als Informatiker würde ich ja sagen, dass Relationen hier eigentlich die ideale Abbildung wären. Die was enthalten sollen? Alle Straßen? Oder alle Hausnummern? Eine Relation aller Straßen von Hamburg sollte eine gewissermaßen unhandliche Größe erhalten. Hmmm, was heißt schon unhandlich. Alles eine Frage der Tools, die damit umgehen. Mit den aktuellen Mitteln ist es zudem quasi unmöglich, eine solche Relation mit einer breiten und unterschiedlich motivierten und versierten Benutzerbasis zu pflegen. Lieber kleine, handliche und eindeutige Infos an einzelnen Objekten, quasi Referenzen vom Einzelobjekt zum parent, das sollte dir als Informatiker auch geläufig sein. ;-) Ok, einverstanden, dass man es in dieser Richtung löst. Nur leider gibt es das nicht in der OSM-Datenbank. Es gibt nur die Möglichkeit, Strings zu erfassen, die mit Glück dem Namen des Parent entsprechen. Du kannst aber mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, dass du mindestens Tippfehler im einstelligen Prozentbereich hast. Namen aus der realen Welt sind einfach als ID wegen der Wahrscheinlichkeit für Tippfehler, Zeichensatzencodings, etc. relativ ungeeignet. -- Gernot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ortssuche: Openrouteservice.de x-fach schneller als Openstreetmap.org
Wie gelingt es dem Openroutservice, eine dermaßan fixe Suche anzubieten, die vor allem auch noch mit sinnvollen Treffern aufzuwarten? Oder ist die ORS-Suche so deutschlandfixiert, dass sie international nicht weiterhelfen würde? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortssuche: Openrouteservice.de x-fach schneller als Openstreetmap.org
Hallo, Johann H. Addicks schrieb: Wie gelingt es dem Openroutservice, eine dermaßan fixe Suche anzubieten, die vor allem auch noch mit sinnvollen Treffern aufzuwarten? Oder ist die ORS-Suche so deutschlandfixiert, dass sie international nicht weiterhelfen würde? Auf der FOSSGIS hat Pascal erzählt, dass die zur Routenberechnung nötigen Daten komplett im Hauptspeicher vorliegen, ich meine mich an an 48GB RAM zu erinnern. Nur so können sie im ORS eine so schnelle Routenberechnung ermöglichen. Ob die Suche auf die selben Daten zugreift weiß ich nicht, vermute es aber. Was die Qualität der Ergebnisse angeht, dazu kann ich dir nichts erzählen, aber der Namefinder war ja schon öfter Thema und es gab ja auch wohl verbesserte Varianten. Wenn ich mich recht erinnere, waren teilweise zumindest in der falschen Sprache implementiert (muss es Ruby sein). Grüße, Fabian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] API-Umbau News auf openstreetmap.de
Gerade bemerkte ich, dass auf http://www.openstreetmap.de/ keinerlei Meldung dazu steht. Noch ist es nicht zu spät, um eventuell doch den einen oder anderen zu erreichen, der sich wundert... Zudem wäre statt oder zusätzlich zu einer Meldung Die API ist momentan wegen Umstellung auf Version 0.6 im Nur-Lese-Modus eine allgemeinverständlichere Formulierung wie Momentan ist es ist nicht möglich, mit den Editoren vorgenommene Änderungen hochzuladen. Die etwas weniger technik-affinen Mapper werden das sicher zu schätzen wissen. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Christoph Wagner freemaps@googlemail.com wrote: Testet sie aus und gebt mir Rückmeldung. Die zugehörigen Style- und Typfiles werde ich später noch hochladen. Das Teil routet im Radfahrermodus konsequent auch über tracktype=grade5 ohne dadurch wirklich viel Weg zu sparen. Ehrlich gesagt empfinde ich grade4 und grade5 nicht unbedingt als geeignet für Radfahrer. Kann man das irgndwie anpassen?Zum Beispiel dadurch, dass man die Geschwindigkeiten für diese Tracktype auf maximal 5km/h stellt und für grade1 und grade2 deutlich höher? Konkret geht es um diesen Weg hier: http://www.openstreetmap.org/browse/way/4433134 Falls Du das irgendwie ausprobieren kannst. Gruss Sven -- Software is like sex; it's better when it's free (Linus Torvalds) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] API-Umbau News auf openstreetmap.de
malenki o...@malenki.ch writes: Zudem wäre statt oder zusätzlich zu einer Meldung Die API ist momentan wegen Umstellung auf Version 0.6 im Nur-Lese-Modus eine allgemeinverständlichere Formulierung wie Momentan ist es ist nicht möglich, mit den Editoren vorgenommene Änderungen hochzuladen. Die formulierung ist sowieso etwas schief. Für die technik-affinen müsste es heißen: Die datenbank ist momentan wegen umstellung der API auf version 0.6 im nur-lese-modus. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] max??-Attribute als Node
hi ! in manchen Typ-File sowie in JOSM gibt es für die max??-Tags (maxheight / maxwidth etc.) dieses als Node - obwohl in den MapFeatures (http://wiki.openstreetmap.org/wiki/DE:Map_Features) nur als Way definiert. Auch in http://wiki.openstreetmap.org/wiki/DE:Key:access finde ich keinen Node-Hinweis. Liegt hier ein Fehler vor oder wie ist die allg. Handhabung. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] API-Umbau News auf openstreetmap.de
Karl Eichwalder schrieb: malenki o...@malenki.ch writes: Zudem wäre statt oder zusätzlich zu einer Meldung Die API ist momentan wegen Umstellung auf Version 0.6 im Nur-Lese-Modus eine allgemeinverständlichere Formulierung wie Momentan ist es ist nicht möglich, mit den Editoren vorgenommene Änderungen hochzuladen. Die formulierung ist sowieso etwas schief. Für die technik-affinen müsste es heißen: Die datenbank ist momentan wegen umstellung der API auf version 0.6 im nur-lese-modus. Ich wollte schreiben eine Meldung _wie_, die Meldung an sich habe ich frei aus dem Gedächtnis formuliert. In der deutschen Informations-Mail ist so formuliert wie du sagtest. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: wmsplugin/Yahoo am Mac
Moin, ich wollte die Downtime nutzen, um endlich auf meinem Mac (10.5.6 Intel) das WMS-Plugin für Yahoo-Bilder zum Laufen zu bringen. Immerhin habe ich es schon geschafft, dass webkit-image losläuft, und www.heise.de erfolgreich rendert. (Qt 4.5.0 aus Sourcen kompiliert und installiert, und dann webkit-image übersetzt.) Beim Aufruf von file:Users/stb/.josm/plugins/wmsplugin/ymap.html?bbox=10.0214546,53.5740061,10.0245090,53.5770605srs=EPSG:4326width=500height=500 bekomme ich aber nur eine graue Seite (aber mit Yahoo!-Logo) zurück. (Sowohl in JOSM als auch beim Versuch von Hand.) Die selbe URL in Safari oder Firefox zeigt mir Satellitendaten, es scheint also was mit webkit-image zu tun zu haben. Hat jemand einen Tipp für mich? Gruß, Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Sven Geggus schrieb: Das Teil routet im Radfahrermodus konsequent auch über tracktype=grade5 ohne dadurch wirklich viel Weg zu sparen. Ehrlich gesagt empfinde ich grade4 und grade5 nicht unbedingt als geeignet für Radfahrer. Kann man das irgndwie anpassen?Zum Beispiel dadurch, dass man die Geschwindigkeiten für diese Tracktype auf maximal 5km/h stellt und für grade1 und grade2 deutlich höher? Hi, meine Version routet auf max. grade3. Ich verzichte bewusst (wegen Übersichtlichkeit) auf Höhenlinien, Grenzlinien und Stromleitungen. Radwege = blau gepunktet (wie in Mapnik) http://www.badongo.com/file/14527315 Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status-Update: Adress-Suche bei Garmin-Karten
Hallo. Am Sonntag 19 April 2009 17:24:12 schrieb Gernot Hillier: Ok, einverstanden, dass man es in dieser Richtung löst. Nur leider gibt es das nicht in der OSM-Datenbank. Es gibt nur die Möglichkeit, Strings zu erfassen, die mit Glück dem Namen des Parent entsprechen. Du kannst aber mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, dass du mindestens Tippfehler im einstelligen Prozentbereich hast. Das ist ein Informatikerargument. Wenn du an jeder Straße Informationen der Art name=Foobarstraße city=X-Y-Stadt hast, dann ist die Wahrscheinlichkeit für einen Fehler bei name erstmal gleich groß wie bei city. Und wie viele falsch geschriebene Straßennamen haben wir in der Datenbank? Meiner Beobachtung nach maximal im Promillebereich. Für die Städtenamen tippe ich also auf nicht mehr. Zudem kann man recht einfach mit Tools ausgeben lassen, welche Ortsnamen in einer gewissen bounding-Box gesetzt wurden und erkennt Tippfehler sehr schnell. Editoren können einem dabei einfach helfen, siehe KA- Hausnummernschema. Namen aus der realen Welt sind einfach als ID wegen der Wahrscheinlichkeit für Tippfehler, Zeichensatzencodings, etc. relativ ungeeignet. Du siehst das zu sehr als Informatiker. Alles braucht eine (numerische) ID, diesen Drang kenne ich. ;-) Aber die Praxis zeigt, dass 1. Namen als ID funktionieren. Siehe KA-Schema und was man schon jetzt damit alles machen kann und 2. allem eine zusätzliche ID zu geben (maschinen- oder menschenlesbar) die Komplexität stark erhöht und die Fehler dann auf anderem Level passieren und nicht so einfach erkennbar bzw. behebbar sind wie einfache Tippfehler bei Namen. Gruß, Bernd -- Columbus hatte in Wirklichkeit vier Schiffe - das vierte segelte über die Kante signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Stephan Schildberg schrieb: Martin Koppenhoefer schrieb: Am 19. April 2009 13:55 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Da wir hier in Deutschland halt *nur* spezielle Begriffe für Burg, Schloß und Festung haben, fällt uns das hier halt eher auf (bzw. stört uns eher). wir haben halt Burgen, die es woanders so gar nicht gibt (wobei ich nicht sage, dass der Verbreitungsraum von Burgen mit den heutigen deutschen Staatsgebiet oder Sprachgebiet deckungsgleich ist). Nehmt doch: historic=palace historic=fortress ab wann ist denn ein Palast historic? Gehört da z.B. ein Palast von Saddam Hussein oder Ceaucescu dazu? Einer von Anfang des 20. Jh.? Einer von Ende des 18. Jh.? Einer spätrömischer? Ein babylonischer? Einer von Kim Jong Il? Ich finde historic im Grunde problematisch, weil es alles sein kann von 10 Jahre alt aber Machtverhältnisse inzwischen geändert bis zum akkadischen Palast aus dem 2. Jahrtausend v.Chr. ++ Als historisch bezeichnet doch nur die politisch führende Meinung der Gegenwart. Sind der Palast der Queen in London und Windsor Castle historisch? Weder der Baustil noch die komplett abgeschlossene Epoche (welche immer aus der Gegenwart und je nach Betrachter interpretiert wird) liegt hier vor. Was ist mit Kunstburgen, Kunstschlössern (Berliner Stadtschloß, Neuschwanstein um ein paar bekanntere zu nennen) ? Historisch ist alles von nun an oder? Ach so, mir war nicht bewußt, daß die: Ich suche keine Lösung, sondern ein Problem Fraktion wieder etwas Freizeit übrig hat. Aber schwafelt ruhig weiter ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte f�r ganz Deutschland
Hi, On Sun, 19 Apr 2009 09:57:18 +0200, Christoph Wagner wrote: ich habe die Downzeit der API sinnvoll genutzt und es endlich geschafft eine halbwegs vernünftige Garmin-karte für ganz Deutschland zu produzieren. Die kommt gar nicht schlecht, vor allem die Bugs als eigene Karte im Gerät wählbar zu machen ist gut. Die Karte ist routingfähig (auch über Kachelgrenzen), besitzt abschaltbare Höhenlinien, FIXMEs, Openstreetbugs und Adressen. Nach Adressen suchen konnte ich im zumo nicht - er verlangt einen Bundesstaat bei der Adresseingabe, kennt aber keinen. -- Ciao, Holger (GUS-KOTAL, GUS#1100, GRR#51) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Aktion im Sommer im LK Schwäb isch Hall
Hallo. Am Sonntag 19 April 2009 17:10:49 schrieb André Reichelt: Wer oder was ist denn Bohmte? http://wiki.openstreetmap.org/index.php/Akwebgis_igf_mapping_veranstaltung http://www1.ndr.de/ratgeber/technik/internet/bohmte110.html Ihr solltet also eher die ländlichen Ortschaften ins Visier nehmen oder (das wäre mein spontaner Favorit) das Problemkind Crailsheim. Crailsheim ist momentan noch echt dürftig. Da kannst du ohne Busunternehmen einfach von einem zentralen Punkt loslaufen und jedes Team geht in ne andere Richtung. Und jeder findet ne Menge Neuland. Das stimmt leider und ist zum Großteil auch meine Schuld, denn ich bin aus Crailsheim. Ich würde lügen, wenn ich sage dass ich letzteres nicht gewusst hätte. :) Aber unabhängig davon würde ich sagen, wenn du da auf geringerem Raum die Stadt mappen kannst, hast du weniger Aufwand. Wenn du es natürlich schaffst, einen Busunternehmer zu begeistern, umso besser, dann kann es auch die Pampa sein. :) Gruß, Bernd -- Ein Finanzgenie ist ein Mann, der sein Geld schneller verdient, als seine Frau es ausgeben kann. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu asia.osm von der Geofabrik
Frederik Ramm schrieb: Hi, Stefan Dettenhofer (StefanDausR) wrote: Kann es sein, dass in der Asia.osm der Teil von Asien fehlt, dessen Koordinaten im Bereich von -180.00 (W180) bis ca. -168.00 (W168) liegt, oder bin ich zu dumm, den Bereich richtig mit osmosis auszuschneiden? Ich glaube, diese Daten fehlen - weil *ich* nicht wusste, wie ich ein Osmosis-Polygon konstruiere, das ueber die 180°-Grenze hinausgeht. Bist aber bislang der erste, der deswegen fragt ;-) Bye Frederik Hallo Frederik, Analoges gilt auch für australia-ociania.osm! Übrigens gibt es Überschneidungen von australia-ociania.osm mit asia.osm: Indonesien und die ganze Inselwelt sind in beiden Dateien vorhanden. Die betroffenen Gebiete siehst Du hier: http://wince.dentro.info/koord/osm/TileMap.htm Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Christoph Wagner schrieb: Hallo Mitmapper, ich habe die Downzeit der API sinnvoll genutzt und es endlich geschafft eine halbwegs vernünftige Garmin-karte für ganz Deutschland zu produzieren. Die Karte könnt ihr hier runterladen: http://www.juergen-frank.de/osm/gmapsupps/germany/gmapsupp.img.tar.bz2 Die Karte ist routingfähig (auch über Kachelgrenzen), besitzt abschaltbare Höhenlinien, FIXMEs, Openstreetbugs und Adressen. Es sind für die verschiedenen Layer mehrere Typfiles eingebaut. Wie ich das alles genau gemacht habe, werde ich noch dokumentieren, hatte bisher aber keine Zeit dazu. Alles was ich weiß, werde ich hier dazu nach und nach einpflegen: http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map Die aktuelle Dokumentation stimmt teilweise schon nicht mehr! Testet sie aus und gebt mir Rückmeldung. Die zugehörigen Style- und Typfiles werde ich später noch hochladen. Beim Garmin Mobile XT (auf WM6) funktioniert die Adresssuche leider nicht so richtig. Zumindest weiß ich nicht wie ;-) Bei der Adresssuche wird zuerst nach Bundesstaat gefragt. Aller der folgenden Versuche führten zu keinem Ergebnis und somit auch nicht weiter in der Adresssuche. keine Eingabe, Berlin, Brandenburg, Deutschland, DEU, B, BRB Hat jemand eine Idee, wie man auch hier eine Adresssuche erreichen kann? -- Gruß Mario signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Am 19.04.09 schrieb Holger Issle: Die kommt gar nicht schlecht, vor allem die Bugs als eigene Karte im Gerät wählbar zu machen ist gut. Kann man die Layer beim etrex * HCx auch einzeln an-/abwählen? Die Adresssuche funktioniert, bei frisch gefluteten Seen hab ich sogar Tiefenlinien. Gruß, Fabian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: wmsplugin/Yahoo am Mac
Ein unendliches Thema Yahoo/JOSM und der MAC ... Wer da ne funktionierende Wiki-Anleitung schreibt wird in mein Nachtgebet eingeschlossen. Am 19. April 2009 19:22 schrieb Stefan Bethke s...@lassitu.de: Moin, ich wollte die Downtime nutzen, um endlich auf meinem Mac (10.5.6 Intel) das WMS-Plugin für Yahoo-Bilder zum Laufen zu bringen. -- Wikipedia -- http://tools.wikimedia.de/~flacus/IWLC/ OSM -- http://osm.flacus.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] max??-Attribute als Node
Jan Tappenbeck schrieb: hi ! in manchen Typ-File sowie in JOSM gibt es für die max??-Tags (maxheight / maxwidth etc.) dieses als Node - obwohl in den MapFeatures (http://wiki.openstreetmap.org/wiki/DE:Map_Features) nur als Way definiert. Auch in http://wiki.openstreetmap.org/wiki/DE:Key:access finde ich keinen Node-Hinweis. Liegt hier ein Fehler vor oder wie ist die allg. Handhabung. Schau mal hier auf der Liste - muss so etwa vor drei Monaten Thema gewesen sein. Da gab es auch die Meinung dass bevor man einen way nur wegen einer Unterführung unterbricht lieber einen node setzt. Ich bin der Ansicht dass diese Information ausschliesslich an ways und nicht an nodes gehört - einfacher für die Auswertung da man nicht auf mehrere Möglichkeiten achten muss und eindeutig für welches wayelement gültig... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Guten Abend an alle, Ich sehe jetzt auch keinen Sinn darin, deutsche Begriffe als Values zu verwenden, wenn sonst alles auf Englisch abgefaßt ist und ich kann auch das Übersetzungsproblem nicht nachvollziehen. Dann versuche ich es noch mal zu erklären: Burg = castle Schloß = palace oder manor Festung = fortress Wo ist das Problem? Das Leben ist nicht so einfach wie es scheint. Burg = castle stimmt nicht. Burg bezeichnet in der deutschen Sprache im engeren Sinne den wehrhaften Wohnsitz des Adels in Europa sowie andere bewohnbare Wehrbauten des Mittelalters, die während des 11.-15. Jahrhunderts errichtet wurden (gekürzt nach Wörterbuch der Burgen, Schlösser und Festungen. Stuttgart 2004, S. 90.), Schloss dagegen das Gebäude eines Landesherrn in nachmittelalterlicher Zeit bis in das 19./20. Jh. (ebd. S. 231). Der Übergang von der Burg zum Schloss - so auch in den zeitgenössischen Quellen - setzte aber bereits im 14. Jh. ein. Siehe auch http://de.wikipedia.org/wiki/Burg und http://de.wikipedia.org/wiki/Schloss_(Architektur) Bei dem englischen Begriff castle gibt es diese zeitliche und funktionelle Trennung nicht, die uns geläufig ist und bei den meisten anderen mittel-, nord- und osteuropäischen Sprachen auch vorkommt (da: borg / slot; sw: borg / slott; cz: hrad / zámek, sk: hrad / zámok, hu: vár / kastély etc. So ist z.B. Neuschwanstein ein castle, aber (fast) niemand würde Burg Neuschwanstein sagen (im Internet gibt es heutzutage alles ;-). Es gibt noch hunderte Beispiele mehr, eins noch: Das kleine Landschloss Tiefurt bei Weimar ( http://de.wikipedia.org/wiki/Schloss_Tiefurt ), Ende des 16. Jahrhunderts errichtet und 1765 umgebaut und erweitert, läuft unter small castle. Eine Burg gab es in Tiefurt nicht. Auch fast alle Forts in Übersee sind im englischen castle, aber im Deutschen nie Burg, sondern eben Fort. Wenn man den Begriff halbwegs trifft und im Wiki gut definiert, sollte das ausreichen. Der Begriff castle, der als Überbegriff zur Not noch taugt (historic=castle), trifft es nicht mal halbwegs und ist auch (im Wiki) nicht gut definiert. Hinzu kommen andere Phänomene, die es im Deutschen, aber erst recht nicht im Englischen gibt, zum Beispiel die kleinen dörflichen Adelssitze, die im Tschechischen tvrz oder im slowakischen kaštieľ heißen, wobei auch diese beiden Begriffe nicht deckungsgleich sind. Dafür gibt es im Englischen Begriffe für Burgtypen und Einzelbauten, die wir im Deutschen nicht kennen, wie etwa keep. Wir haben mal versucht, das Ganze unter http://wiki.openstreetmap.org/wiki/DE_talk:Tag:historic%3Dcastle#Internationale_Entsprechungen ein wenig zu sortieren. Ich würde vorschlagen, die Diskussion zieht dahin um. Spielt da nciht auch noch das Chaos um das Tag ruin mit rein? Die einen Taggen z.B. als Castle, ruined = yes, die anderen als historic=ruin. Damit kann man leider Burgen-, Kirchen-, Industrie- und 3.Reichruinen nicht voneinander unterscheiden. Gibt's dazu schon weiterführende Gedanken? Eigentlich spielt das hier nicht mit rein. Ich hatte vor geraumer Weile aber schon mal aus dem gleichen Grund vorgeschlagen, historic=ruin nicht mehr zu verwenden: [Talk-de] historic=ruins abreißen, historic =... aufräumen http://www.mail-archive.com/talk-de@openstreetmap.org/msg21738.html Stephan Schildberg hat das Übersetzungsproblem richtig beschrieben. Die beste Möglichkeit, die ich daher sehe, ist, dass wie die in den einzelnen Kulturräumen historisch verankerten und daher von der überwiegenden Zahl der Maper und Kartennutzerinnen intuitiv richtig verwendeten Begriffe zu nehmen. So wird es auch in der internationalen Burgenforschung gemacht, die Begriffe werden beibehalten, weil jeder Übersetzungsversuch zu Begriffsverwirrung und Unklarheiten führt. Wer sich selbst überzeugen möchte: Konferenz Castrum Bene Terminologie und Typologie in der Burgenforschung 11. Castrum Bene Tagung, 03-06. 09. 2009. UNGARN, Gyöngyös-Mátrafüred http://www.castrumbene.hu/index.php?oldal=konferenz [Ich werde da wahrscheinlich hinfahren.) Es wäre dafür notwendig, die jeweiligen Definitionen für diese Begriffe zu kennen und diese dann zu übersetzen, nicht die Begriffe selbst. Ein ähnliches Problem stellt sich ja auch bei einigen archäologischen Befunden, z.B. den verschiedenen Typen von Großsteingräbern. Auch hier gibt es in unterschiedlichen Regionen verschiedene Typen und entsprechend keine adäquate Bezeichnung im Englischen etwa für Großsteingrab, weshalb auch in englischsprachigen Arbeiten das deutsche Wort Verwendung findet. http://wiki.openstreetmap.org/wiki/DE:Tag:historic%3Darchaeological_site Es wäre kein Vorteil, wenn englischsprachige User_innen zwar eine ungefähre Idee davon bekommen, was sie vor Ort sehen, die Leute vor Ort in dem jeweiligen Land aber mit völlig unüblichen Begriffen konfrontiert werden, die den Kern der Sache nicht treffen. Die deutschen Begriffe Schloss und Palast könnte man hier synonym
Re: [Talk-de] Garminkarte für ganz Deutschland
Chris-Hein Lunkhusen schrieb: Hi, meine Version routet auf max. grade3. Ich verzichte bewusst (wegen Übersichtlichkeit) auf Höhenlinien, Grenzlinien und Stromleitungen. Dabei sind doch gerade Stromleitungen noch eine gute Orientierungshilfe... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] max??-Attribute als Node
Jan Tappenbeck schrieb: hi ! in manchen Typ-File sowie in JOSM gibt es für die max??-Tags (maxheight / maxwidth etc.) dieses als Node - obwohl in den MapFeatures (http://wiki.openstreetmap.org/wiki/DE:Map_Features) nur als Way definiert. Auch in http://wiki.openstreetmap.org/wiki/DE:Key:access finde ich keinen Node-Hinweis. Liegt hier ein Fehler vor oder wie ist die allg. Handhabung. In der Regel werden diese Tags auf Ways benutzt. Allerdings gibt es auch die Argumentation, dass sehr kurze Wegstücke (z.B. kurze Unterführung) eventuell auch durch einen einzelnen Node repräsentiert werden können. Damit spart man sich das Aufteilen und muss nicht mit sehr kurzen Stücken hantieren. Andererseits kann man auch argumentieren, dass kein Wegstück so kurz ist, dass es durch einen Node adäquat repräsentiert werden kann. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Links
Hallo, ich hab eine kleine Seite zusammengestellt, auf der zahlreiche Links zu SlippyMaps (und auch Ausgewählte andere) zu finden sind. Das Besondere daran ist jedoch, dass die Adressen automatisch um die Koordinaten und den Zoom erweitert werden, sofern im Skript angegeben. Zwar gibt es wohl auch schon einige andere Tools, die Ähnliches leisten, aber vielleicht findet es ja trotzdem jemand nützlich. Insbesondere auch zusammen mit der Firefox Extension. http://osmtools.de/osmlinks/ Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Aktion im Sommer im LK Schwäb isch Hall
Bernd Wurst schrieb: Das stimmt leider und ist zum Großteil auch meine Schuld, denn ich bin aus Crailsheim. Ich würde lügen, wenn ich sage dass ich letzteres nicht gewusst hätte. :) .. und es haben sich schon mehrere gefragt warum es in Crailsheim noch so dünn aussieht mit OSM - da muss der GPS-Empfang ziemlich schlecht sein ;-) Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] highway=service vs highway=residential
Hi, wie würdet ihr sowas taggen? * Wohngebiet * Zufahrt zu etwa einer Handvoll Mehrfamilienhäusern * wird praktisch nur von Anwohnern / Besuchern benutzt * abgesenkter Bordstein Punkt 1 würde ja eigentlich highway=residential bedeuten, ist mir vom Gefühl her (und wegen Punkt 2-4) zu gross. Also eher highway=service? Aber gibt's das in Wohngebieten überhaupt? (Die Beispiele im Wiki sind alle eher auf Zufahrt zu Infrastruktur). Und: Wie sieht's aus, wenn das Ding einen Strassennamen (und sei es nur der gleiche, wie die nächst-grössere) hat? Kann es dann noch highway=service sein? Hier mal 2 Beispiele aus googlemaps: http://maps.google.de/?ie=UTF8ll=53.593976,9.951009spn=0.000688,0.002747t=hz=19 http://maps.google.de/?ie=UTF8t=hll=53.569351,10.160063spn=0.001376,0.003455z=18 Eins davon ist zur zeit highway=service, das andere highway=residential - was meint ihr? Gruss UncleOwen / Sören ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Links
Sebastian Hohmann schrieb: [...] http://osmtools.de/osmlinks/ Schick! Über Google in der Auflistung könnte man diskutieren Falls du noch ein paar Maps hinzufügen willst, wirst du vielleicht hier fündig: http://wiki.openstreetmap.org/wiki/List_of_OSM_based_Services Ich werde deine Seite mit der Liste abgleichen. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service vs highway=residential
On Sun, Apr 19, 2009 at 08:59:41PM +0200, UncleOwen wrote: Subject: [Talk-de] highway=service vs highway=residential Hi, wie würdet ihr sowas taggen? * Wohngebiet * Zufahrt zu etwa einer Handvoll Mehrfamilienhäusern * wird praktisch nur von Anwohnern / Besuchern benutzt * abgesenkter Bordstein Punkt 1 würde ja eigentlich highway=residential bedeuten, ist mir vom Gefühl her (und wegen Punkt 2-4) zu gross. Also eher highway=service? Aber gibt's das in Wohngebieten überhaupt? (Die Beispiele im Wiki sind alle eher auf Zufahrt zu Infrastruktur). Und: Wie sieht's aus, wenn das Ding einen Strassennamen (und sei es nur der gleiche, wie die nächst-grössere) hat? Kann es dann noch highway=service sein? Hier mal 2 Beispiele aus googlemaps: http://maps.google.de/?ie=UTF8ll=53.593976,9.951009spn=0.000688,0.002747t=hz=19 http://maps.google.de/?ie=UTF8t=hll=53.569351,10.160063spn=0.001376,0.003455z=18 Eins davon ist zur zeit highway=service, das andere highway=residential - was meint ihr? highway=residential service ist fuer mich zufahrt zu einem hof, zufahrt zu einem firmengelaende. Aber immer singular. D.h. sobald es mehr als eins ist ists fuer mich mehr - Also Faustregel - ausnahmen gibt es immer. Tendentiell ist es ja eine Oeffentliche Straße mit Hausnummern/Adresen und dem ganzen Zinober mit Lieferverkehr. Ein weiterer Aspekt (Eher soft-fact) ist ja das die ganzen Router eher highway=service ignorieren - d.h. nicht dort routen/hineinrouten. Macht die Straße dann Sinn? Eine Hofzufahrt macht ja sinn als highway=service weil das Navi mich bis zur Kreuzung zu dieser service road navigiert und dort dann eine kleine 4711 auf einem Schild steht und ich eben dort hineinfahre. Wenn aber dort mehr als ein Haus steht moechte ich ja das das Navi mir vor der richtigen Haustuer vermeldet das das Ziel erreicht ist. So - und nun warten wir auf die anderen Meinungen ;) Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service vs highway=residential
UncleOwen schrieb: Punkt 1 würde ja eigentlich highway=residential bedeuten, ist mir vom Gefühl her (und wegen Punkt 2-4) zu gross. Also eher highway=service? Aber gibt's das in Wohngebieten überhaupt? (Die Beispiele im Wiki sind alle eher auf Zufahrt zu Infrastruktur). Und: Wie sieht's aus, wenn das Ding einen Strassennamen (und sei es nur der gleiche, wie die nächst-grössere) hat? Kann es dann noch highway=service sein? Klar ist das hightway=service. Solche Seitenäste von Residentials mit bis zu (gefühlten) 50m Länge oder max. 10 Hausnummern sind ein Serviceweg. Eine betonierte Piste zu einer kleinen Pumpstation oder einer Umspannstation, wo vielleicht einmal in der Woche (oder noch seltener) jemand vorbeischaut, ob die das Ding wirklich noch funktioniert wie in der Leitwarte signalisiert: Das ist kein Service, sondern ein Track, meintwegen als grade1. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] highway=unclassified vs =residential vs. =road (Re: routing über highway=path)
salv...@t-online.de schrieb: also in einem Wohngebiet ist die Straße die alles verbindet (also Verbindungscharakter hat) eine tertiary. unclassified gibts innerorts meiner Meinung nach nicht (es sei denn es hat außerörtlichen Charakter ohne Verbindungscharakter). Klar gibt es innerorts unclassified. Das sind die breiten Erschließungsstraßen in Industriegebieten, in denen sich auch in den Kurven problemlos zwei Sattelschlepper mit extralangen Curtainrailern entgegenkommen können, ohne dass die sich verhaken. Ansonsten würde ja niemand die Flächen Abseits der Gewerbegebiets-Hauptstraße haben wollen, wenn da keine LKW (gut) hinkommen. Bahn-Gleisanschluss war leider früher einmal. Was ich leider immer wieder feststelle, dass highway=unclassified von Yahoo-Mappern eingetragen wird, obwohl sie eigentlich highway=road setzen wollten. Von daher ist es nie falsch, bei jedem unclassified zweimal hinzuschauen. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Routingoptmierung
Johann H. Addicks schrieb: Tobias Knerr schrieb: Meiner unwesentlichen Meinung nach sollten Anwendungen versuchen, Implikationen unterstützen, wie sie etwa im Wiki auch genannt werden. Wenn ich es richtig verstanden haben, dann sprechen wir in diesem konkreten Fall über ein Fehlrouting, welches dadurch möglich wurde, dass ein Kreisverkehr a) Nicht als Kreisverkehr getagt war und gleichzeitig richtig b) der Oneway falschherum eingetragen war. Nein, oneway war gar nicht eingetragen, nur die way-segmente waren entgegen der Durchfahrtrichtung angegeben. Ich glaube nicht, dass in so einem Szenario den Router eine Schuld trifft. Nein- darum ging es auch nicht - der eigentliche Hintergrund war zu wissen was für das richtige durchrouten des Kreisverkehrs von Bedeutung ist; oneway oder roundabout. Fazit: oneway muss nicht extra getaggt werden, roundabout ist ein muss. Bliebe noch die Frage wie ein unechter Kreisverkehr getaggt wird (ohne dem Kreisverkehrszeichen) Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service vs highway=residential
Florian Lohoff schrieb: service ist fuer mich zufahrt zu einem hof, zufahrt zu einem firmengelaende. Aber immer singular. D.h. sobald es mehr als eins ist ists fuer mich mehr - Also Faustregel - ausnahmen gibt es immer. Hier gibt's häufig diese Zufahrten für 2-4 Häuser. Irgendwelche absurden Konstruktionen, um die Hintergrundstücke zu erschließenen. Steht dann Schild dran Helmut Frommbeger Weg 79a/81a oder Fichtenweg 5-9 (was dann auch nur 3 Häuser sind). Häufig nichtmal mit einem Hinweis, dass es gar keine Wendemöglichkeit gibt, wenn beim letzten Haus die Auffahrt vor der Garage durch ein Auto belegt ist... Aber das sind dann eher die Leiden des OSM-KFZ-Mappers... andere verirren sich ja nicht in solche Stichwege, bei denen von vornherein klar ist, dass man da nirgends hinkommt. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterschied zwischen Einzelstufe und Treppe sinnvoll?
Am 14. April 2009 16:19 schrieb Martin Koppenhoefer dieterdre...@gmail.com: ich habe zu den Treppen auch nochmal eine Anmerkung: seit ich bei OSM dabei bin, zeichne ich die Treppen grundsätzlich in der Richtung von unten nach oben, weil ich das z.B. auch von Bauzeichnungen so gewohnt bin. In der Saechsischen Schweiz gibt es einige An-/Abstiege, die als Treppen ausgefuehrt sind, und die quasi Einbahnstrassen sind. Ich habe diese als oneway=yes getaggt. Die meisten sollen nur bergwaerts begangen werden, daher gibt es mit der Architektenkonvention keine Kollision, aber moeglicherweise gibt es auch explizite Nur-Abstiege. Da koennte man freilich oneway=-1 dransetzen, aber besonders schoen ist das nicht. Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=unclassified vs =residential vs. =road (Re: routing über highway=path)
Johann H. Addicks schrieb: salv...@t-online.de schrieb: also in einem Wohngebiet ist die Straße die alles verbindet (also Verbindungscharakter hat) eine tertiary. unclassified gibts innerorts meiner Meinung nach nicht (es sei denn es hat außerörtlichen Charakter ohne Verbindungscharakter). Klar gibt es innerorts unclassified. Das sind die breiten Erschließungsstraßen in Industriegebieten, in denen sich auch in den Kurven problemlos zwei Sattelschlepper mit extralangen Curtainrailern entgegenkommen können, ohne dass die sich verhaken. Nein - wie breit eine Strasse ist und wer da fahren darf ergibt sich aus den anderen Parametern. Es gibt durchaus auch Wohngebiete mit sehr breiten Strassen. Unclassified sollte dazu verwendet werden um eine gewisse Erschliessungsfunktion darzustellen wenn es für ein tertiary noch nicht reicht - also sowas wie die Hauptzufahrten zu grösseren Wohngebieten.. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service vs highway=residential
UncleOwen schrieb: Hi, wie würdet ihr sowas taggen? * Wohngebiet * Zufahrt zu etwa einer Handvoll Mehrfamilienhäusern * wird praktisch nur von Anwohnern / Besuchern benutzt * abgesenkter Bordstein Punkt 1 würde ja eigentlich highway=residential bedeuten, ist mir vom Gefühl her (und wegen Punkt 2-4) zu gross. Also eher highway=service? Aber gibt's das in Wohngebieten überhaupt? (Die Beispiele im Wiki sind alle eher auf Zufahrt zu Infrastruktur). Und: Wie sieht's aus, wenn das Ding einen Strassennamen (und sei es nur der gleiche, wie die nächst-grössere) hat? Kann es dann noch highway=service sein? Hier mal 2 Beispiele aus googlemaps: http://maps.google.de/?ie=UTF8ll=53.593976,9.951009spn=0.000688,0.002747t=hz=19 http://maps.google.de/?ie=UTF8t=hll=53.569351,10.160063spn=0.001376,0.003455z=18 Eins davon ist zur zeit highway=service, das andere highway=residential - was meint ihr? Wenn es nicht als verkehrsberuhigte Zone (dann living-street)gekennzeichnet ist: Fahren dort praktisch ausschliesslich Anwohner und Besucher auf Anweisung(!) rein, dann service, fährt aber jeder Besucher und Lieferverkehr dort rein ohne schief angeschaut zu werden dann residential... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=unclassified vs =residential vs. =road (Re: routing über highway=path)
Garry schrieb: Johann H. Addicks schrieb: salv...@t-online.de schrieb: also in einem Wohngebiet ist die Straße die alles verbindet (also Verbindungscharakter hat) eine tertiary. unclassified gibts innerorts meiner Meinung nach nicht (es sei denn es hat außerörtlichen Charakter ohne Verbindungscharakter). Klar gibt es innerorts unclassified. Das sind die breiten Erschließungsstraßen in Industriegebieten, in denen sich auch in den Kurven problemlos zwei Sattelschlepper mit extralangen Curtainrailern entgegenkommen können, ohne dass die sich verhaken. Nein - wie breit eine Strasse ist und wer da fahren darf ergibt sich aus den anderen Parametern. Es gibt durchaus auch Wohngebiete mit sehr breiten Strassen. Unclassified sollte dazu verwendet werden um eine gewisse Erschliessungsfunktion darzustellen wenn es für ein tertiary noch nicht reicht - also sowas wie die Hauptzufahrten zu grösseren Wohngebieten.. Garry eine Hauptzufahrt zu mehreren Wohngebieten klingt eher nach tertiary (inner-regionaler Verkehr). Je nachdem wie groß/klein/nicht existent der Verbindungs/ Durchfahrtscharakter für andere umliegende Gebiete ist kanns aber durchaus ein unclassified sein. Sobald das Wohngebiet anfängt ist es aber auf jeden Fall eine residential (oder eben tertialry oder größer) und nicht unclassified. Unclassified in Industrie- oder Gewerbegebieten als kleinster Straßentyp könnte dagegen gut klappen; aber sobald der Way irgendeine Relavanz für den Durchgangsverkehr hat sollte man imho tertiary setzen. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] API-Umbau News auf openstreetmap.de
malenki o...@malenki.ch [Sun, Apr 19, 2009 at 05:49:49PM CEST]: Gerade bemerkte ich, dass auf http://www.openstreetmap.de/ keinerlei Meldung dazu steht. Noch ist es nicht zu spät, um eventuell doch den einen oder anderen zu erreichen, der sich wundert... Ich muss zugeben, dass ich da geschlafen habe, aber warum ist es jetzt nicht zu spät? -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ungenutzte Status-Templates raus aus Staedteseiten im Wiki?
Hallo, mir faellt auf, dass eine ganze Anzahl von Staedten im Wiki so eine Status-Tabelle haben mit allerhand Symbolen und Farben, die man vergeben kann oder soll, und in die *noch nie* irgendjemand etwas eingetragen hat. Hier ist eine Liste aller Seiten, die das Status-Template benutzen: http://wiki.openstreetmap.org/wiki/Category:Page_with_status - einige benutzen es wirklich, bei den meisten scheint es nur toter Ballast zu sein. Ich werde ich da nicht einmischen und die Wikiseiten von Staedten aendern, mit deren Mapping ich nichts zu tun habe, aber ich finde, dass eine solche Tabelle fuer den unerfahrenen Nutzer ziemlich abtoernend ist. Was? Was soll ich machen? Welche Farben nehmen? Tankstellen sind vorhanden = Schluessel fu? Hae? Wenn eine Community vor Ort diese Art der Qualitaets-/Vollstaendigkeitsueberpruefung gerne nutzen will, alles klar, kein Problem. Aber diese Art der Darstellung ist *nicht* der projektweite Standard, und niemand soll denken, es waere notwendig oder gar vorgeschrieben, dass man so eine Tabelle ausfuellt. Ich finde es ehrlich gesagt eher schadhaft, wenn so eine Tabelle da auf jeder Stadtseite prangt und voellig ungenutzt ist. Ich moechte jeden ermutigen, der sich fuer einen Ort oder eine Gegend zustaendig fuehlt, dieses Template von den jeweiligen Seiten zu entfernen, falls es nicht benutzt wird. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Routingoptmierung
Hallo, Meiner unwesentlichen Meinung nach sollten Anwendungen versuchen, Implikationen unterstützen, wie sie etwa im Wiki auch genannt werden. junction=roundabout habe ich noch nie gesehen, die wenigen Kreisverkehre hier in Aachen sind als Einbahnstraßen gekennzeichnet. Mit diesem für mich neuen Tag hätte meine Aussage also sein müssen: Natürlich müssen Kreisverkehre als roundabout oder als Einbahnstraßen gekennzeichnet sein. Das oder deshalb weil im Wiki steht: Meiner unwesentlichen Meinung nach sollten Anwendungen versuchen, Implikationen unterstützen, wie sie etwa im Wiki auch genannt werden. - Kreisverkehre ohne Vorfahrt sind keine junction=roundabout. Und soweit ich mich an die Fahrschule erinner haben wir keine Kreisverkehre mehr mit grundsätzlicher Fohrfahrt, es ist an jeder Einmündung einzeln ausgeschildert. Was auch http://de.wikipedia.org/wiki/Kreisverkehr entspricht. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service vs highway=residential
UncleOwen schrieb: wie würdet ihr sowas taggen? * Wohngebiet * Zufahrt zu etwa einer Handvoll Mehrfamilienhäusern * wird praktisch nur von Anwohnern / Besuchern benutzt * abgesenkter Bordstein Wenn es auf öffentlichem Grund liegt dann als residential, wenn es auf Privatgelände liegt dann als service. Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Aktion im Sommer im LK Schwäb isch Hall
Garry schrieb: .. und es haben sich schon mehrere gefragt warum es in Crailsheim noch so dünn aussieht mit OSM - da muss der GPS-Empfang ziemlich schlecht sein ;-) Nein, das hat einen anderen Grund, wie mir verlässliche Quellen mitgeteilt haben. Dort gab es bis vor kurzem nur einen Mapper mit dem Namen AndreR. Der Typ ist Schüler und relativ knapp bei Kasse (gerade erst Führerschein gemacht). Er hat kein eigenes GPS sondern verwendet ab und zu das Navi eines Bekannten. Der ist aber meist geschäftlich unterwegs. Deshalb vertreibt AndreR seine Zeit meist damit, die täglichen 100 Nahrichten hier zu lesen oder er mappt im Lampukistan von Sat-Bildern ab. Schöne Grüße und danke für die Unterstützung (auch an Bernd), André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Johann H. Addicks schrieb: Christoph Wagner schrieb: Die Karte ist routingfähig (auch über Kachelgrenzen), besitzt abschaltbare Höhenlinien, FIXMEs, Openstreetbugs und Adressen. Wie bekommt man denn die Höhenlinien angeschaltet? OSB, Fixmeed, Adrressen(sic!) und Fixmes finde ich in der Auswahl. Momentan hab ich leider noch einen kleinen Bug drin und die Höhenlinien werden als Euro OSM maps in diesem Menü ausgewiesen. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service vs highway=residential
UncleOwen schrieb: - was meint ihr? Ich habe hier einen ähnlichen Fall: Gar nicht weit gibt es einen schmalen Weg (Auto würde Fußgänger blockieren), der zwischen zwei Häusern hindurch eine Zufahrt für zwei Gebäude bildet. Der Weg trägt den selben Namen wie die große Straße mit dem bekannten Hausnummernzusatz. Ich habe das Ganze als Sericeweg verzeichnet. Ich sehe das eindeutig als Zufahrt an, denn der Weg ist zwar öffentlich aber er hat eben keinerlei Verbindungscharakter. Wer nicht zu den beiden Häusern will, wird da nie hochfahren. Ich denke, man sollte alle Zufahrtswege mit abgesenktem Bordstein als Service taggen. André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Routingoptmierung
Dimitri Junker schrieb: Hallo, Meiner unwesentlichen Meinung nach sollten Anwendungen versuchen, Implikationen unterstützen, wie sie etwa im Wiki auch genannt werden. junction=roundabout habe ich noch nie gesehen, die wenigen Kreisverkehre hier in Aachen sind als Einbahnstraßen gekennzeichnet. Mit diesem für mich neuen Tag hätte meine Aussage also sein müssen: Natürlich müssen Kreisverkehre als roundabout oder als Einbahnstraßen gekennzeichnet sein. Das oder deshalb weil im Wiki steht: Meiner unwesentlichen Meinung nach sollten Anwendungen versuchen, Implikationen unterstützen, wie sie etwa im Wiki auch genannt werden. - Kreisverkehre ohne Vorfahrt sind keine junction=roundabout. Wir kommst du auf die Idee?!? Die Vorfahrt im Kreisverkehr wurde hier meiner Erinnerung nach noch nie diskutiert. Es spielt aus meiner Sicht auch überhaupt keine Rolle ... Und soweit ich mich an die Fahrschule erinner haben wir keine Kreisverkehre mehr mit grundsätzlicher Fohrfahrt, es ist an jeder Einmündung einzeln ausgeschildert. Was auch http://de.wikipedia.org/wiki/Kreisverkehr entspricht. Als ich damals Führerschein gemacht habe, gab es (gerüchteweise) unbeschilderte Kreisverkehre mit rechts vor links und beschilderte wo die Vorfahrt eh klar ist. Vom Kreisverkehr mit grundsätzlicher Fohrfahrt höre ich heute zum ersten mal ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
