Re: [OSM-talk] GPS receiver orientation
My entirely annecdotal experience has been that my TomTom 910 takes longer to get a fix when I am moving than stationary. I have an external aerial, so the movement should be the main determinent -- Franc -Original Message- From: "Tim Waters (chippy)" <[EMAIL PROTECTED]> Date: Saturday, Jul 26, 2008 9:22 pm Subject: Re: [OSM-talk] GPS receiver orientation To: "Gervase Markham" <[EMAIL PROTECTED]> CC: talk@openstreetmap.org On 7/26/08, Gervase Markham <[EMAIL PROTECTED]> wrote: > Random question: does the orientation of a GPS receiver make any > difference? If I hold my BGT-11 vertically, will it find it harder to > get and keep a lock than if I hold it horizontally? > >I really want to do some experimentation with getting a lock from cold when >placed on a dashboard, compared to held stationary in your hand, standing >outside of the car. > >Possibly the body acts as a barrier to some satellites, but I've >noticed that locks occur very fast when the GPS is in the car. > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] turn restriction checker
I hacked up a quick perl script to look for common problems in turn restrictions ( http://wiki.openstreetmap.org/index.php/Proposed_features/Routing:_turn_restrictions ) that I am seeing. It checks for:- * missing from,to,via * multiply defined from,to,via * via not part of from and to It needs Geo::OSM; I could 'put it somewhere' if there is any interest and an appropriate place can be suggested cheers -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction checker
I have added a check on whether the 'via' is the first/last node in the from
and to
ways
On Sun, Sep 14, 2008 at 8:12 AM, Nic Roets <[EMAIL PROTECTED]> wrote:
> > Would be great if it could also check this:
> >
> > * a way may not be in any "from" or "to" role if it goes *through* the
> > junction (because in that case the information would be incomplete - you
> > would need to know which part of the way is meant!).
>
> Just to clarify : For example A ends in a T junction where it meets B.
> 'to' is B and goes through so it may be unclear if the restriction
> applies to a left turn or a right turn into B. (Traveling forward /
> backwards in B).
Hmm, I've been slow - I hadn't full appreciated the scope of the problem ;-(
Splitting every way that is part of a turn restriction is going to lead
quite
a few more ways.
Although I'm not sure this is a restriction problem, similar things happen
with
classification changes or bike routes etc
>
>
> Gosmore currently requires the 'restriction' tag because it uses it to
> distinguish between the two. (And it ignores anything with "half",
> "left_right" and "right_left") Specifically it measures the angles
> between the segments and considers turns less than 45 degrees to be
> straight ons and turns more than 135 degrees to be u turns. So there
> have been at least one case in Australia were it was mapped as
> no_right_turn while gosmore considered it a u turn. Of the 3 solutions
> ("no_u_turn", "only_straight_on" and adding a node to give the
> junction a T shape), the mapper chose the latter.
Ahh, I wonder if this is what is causing some of the weirdness I am seeing
with route debugging. Can you send me a permalink to the case in Australia
>
>
> I can't see that I will have time to implement anything else before
> 2009. So I recommend mappers to take the 30 seconds and add the
> restriction tag and perhaps an extra node. (Just like I recommend
> always add bicycle=yes/no to trunk roads).
>
> If both roads goes through, Relation:restriction simply does not have
> enough info. (Relation:xrestriction will have enough info, but is not
> supported or used). So then you have to split at least one of the
> ways. I should just point out that the newbies here in Pretoria have
> blindly recombined ways. In the first case the one way had layer=1 and
> the other didn't have layer set, so the recombine did not result in a
> conflict resolution dialog. This may well happen in cases where ways
> were split to make relation:restriction unambiguous.
>
> O.T. : In the other case(s) the newbie set the layer and name of the
> combined way to "1; 2" and "Old Pretoria Road; Old Pretoria Road"
> respectively.
>
> > Nic has said that he uses the "restriction=..." tag to clarify these. I
> > don't like that idea but if it is used widely then my above rule would
> > have to be lifted for relations with a "restriction..." defined.
>
> There are only 500 odd restrictions. So editing them all should not
> take more than a few hours.
>
> P.S. : I have a very simple proposal for encoding restrictions that
> never requires splitting ways, and unlike xrestriction it will keep on
> working if the someone adds an extra node in the final segment.The
> only drawback is that users will find it difficult. So the best time
> to adopt it will be when one of the editors gets a restriction editor
> function.
>
> Regards,
> Nic
>
> >
> > Bye
> > Frederik
> >
> > --
> > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33"
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk
> >
>
cheers
--
Franc
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] script to make gps traces public ?
Hi, does anyone know of a script that I can use to make all of my gps traces public, as I often forget to click the public checkbox thanks -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] enclosed areas => borders
Hi, I am working on how to import the Australian suburb boundaries. I have these as a set of shapefiles that define an enclosed area for each suburb. The suburbs share many points in common and the outline of one areas overlays the outline of the neighbouring suburb(s) as would be expected. It's fairly easy to de-dupe the points that make up the shape, but I'm struggling with the next part I want to do. I'd like to split the areas in to sets of borders between the two adjoining suburbs. While I believe I have an approach, it's looking annoying and complicated. So, does anyone know if there is a 'standard' algorithm for doing this ? thanks -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] enclosed areas => borders
There are over a million points defining all the suburbs that are in the data set. 90% of these nodes are going to be shared at least two suburbs as the only place where suburbs don't border suburbs is at the coast. It's not clear as to whether which format the data should be imported yet, the talk-au list is discussing this at the moment, personally I am not leaning either way at the moment. However, I still want to be able to split the areas up, even if I put them back together again. I want the option of doing curve simplification, and this gives bad results if it's done on two closed areas that share nodes. On Sat, Feb 7, 2009 at 5:34 PM, Marcus Wolschon wrote: > On Sat, Feb 7, 2009 at 4:17 AM, Franc Carter > wrote: > > > > Hi, > > > > I am working on how to import the Australian suburb boundaries. I have > > these as a set of shapefiles that define an enclosed area for each > suburb. > > > > The suburbs share many points in common and the outline of one > > areas overlays the outline of the neighbouring suburb(s) as would > > be expected. > > > > It's fairly easy to de-dupe the points that make up the shape, but I'm > > struggling with the next part I want to do. I'd like to split the areas > in > > to > > sets of borders between the two adjoining suburbs. While I believe I have > > an approach, it's looking annoying and complicated. > > > > So, does anyone know if there is a 'standard' algorithm for doing this ? > > How many nodes do 2 typical suburbs share? > Many programs (like the adress search in my navigator) cannot yet use > borders split up into multiple polylines grouped in an ordered relation. > Considering that relations are not ordered until api 0.6 is public. > (This is what is done for country-borders.) > > If it's not too many points on the shared polylines I see no problem with > sharing just the nodes and having closed polygons for the suburbs > as more programs will be able to make use of them. > > Marcus > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Australian suburb boundaries
Hi, The Australian Bureau of Statistics has boundaries for the suburbs in Australia under a compatible license (and we have official permission). The talk-au list has been discussing the import and the current thoughts are here:- http://wiki.openstreetmap.org/wiki/Import/Catalogue/ABS_Data#OSM_Representation I'd be appreciate people having a look at what we are proposing and give some feedback. Also, any pointers/caveats on how to actually run the upload so that the server doesn't get swamped while it runs. cheers -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Australian suburb boundaries
On Sun, Feb 22, 2009 at 6:53 PM, Frederik Ramm wrote: > Franc, > > Franc Carter wrote: > >> The talk-au list has been discussing the import and the current thoughts >> are here:- >> > > We did it almost the same way for a German administrative boundary import > in late 2008. Your Wiki table doesn't include the obvious relation tags > (type=multipolygon, boundary=administrative, admin_level=something) but I > guess these were implicit and so you didn't mention them? Also, for the > benefit of relation-unaware software, we usually tagged the member ways with > "boundary=administrative, admin_level=x", with x being the smallest > admin_level of all relations that used this way. We did not add any names or > "state:left=x, state:right=y" to the ways though. This is something I was unsure about - the talk page for this had lots of conflicting opinions ;-( > > We did not see a need to simplify the lines in our case and I cannot > imagine Aussie borders being so detailed that this should be necessary but > you'll know better. There's a lot 'over specification' in the data - 10's of points where one for each end would be fine. > > Multipolygons now support multiple outer rings (see the multipolygon > relation talk page in the Wiki - the "advanced multipolygons" secion really > needs to be moved to the main multipolygon page, it is actually in use and > not just "talk"), so that solves your problem of disjoint suburbs. Ok, I'll have a read and wrap my head around it > > When actually running the upload (we used the bulk_import.pl for this after > creating a suitable .osc file) you should make sure that you *not* attempt > to first upload all the nodes and then all the ways and then all the > relation (which is what we did), because unless the process is over in an > hour or so, you will have eager mappers removing your nodes for obvious lack > of use! In the end I had to download the hourly diffs while I was importing, > searching for "my" node IDs and checking who deleted some, then undelete > them with another script running in parallel, so that my import script would > find the nodes it expected to see. So the lesson learned here was, try and > upload a way as soon as you have the necessary nodes for it, and not at the > end. I thought of this ;-) The file has the data node/way specification just before it is first needed, so hopefully there will only be a short period where the data looks inconsistent cheers > > > Bye > Frederik > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] xapi question
Hi, A while ago I tried to work out how to use osmxapi to extract just the highways that didn't have a name in an area, but couldn't work out how to express this. Is this possible ? or have I just been stupid ;-) thanks -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [EMAIL PROTECTED] memory issues ?
Hi, I've just upgraded my main machine to 3GB of RAM and put a new the latest version of tilesAtHome (Linux) to try to do some rendering - The centre of Sydney (3768,2458) bombs out with what looks like a memory issue:- Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Any ideas on what's wrong ? thanks -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Geolocation photos - what software/hardware do I need?
I do quite a bit of GeoTagging of Photos and having to sync the time every time I got out is annoying (the clock in the camera appears to be crap). So, once there is a suitable cheap gps capable camera I'll be going down this path. On Dec 29, 2007 8:35 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > Hi, > > > Getting your photos tagged directly in your camera is tricky. I heard > > that HP owns the patent for it, but I've seen a couple camera models > > out there that can do it (Ricoh 500SE for one). I think there are some > > other cameras that can work with external GPS receivers, maybe > > bluetooth. > > Years ago there was a series of consumer-level Kodak cameras that had > a serial port an were scriptable in a BASIC-like language, so you > could read NEMA GPS input live while the photo was taken ;-) > > Bye > Frederik > > -- > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] GpsWeather: When conditions for mapping are good
I have found an external antenna also dramatically improved things (for a car), my working assumption is that it is because the external antenna gets an uninterrupted view of more of the sky - i.e not blocked by the roof of the car On Jan 3, 2008 9:16 AM, Jo <[EMAIL PROTECTED]> wrote: > Mike Collinson schreef: > > At 10:11 PM 2/01/2008, ivom wrote: > > > >> Folks! > >> > >> >From time to time, I am suffering from the limited reception > capabilities > >> of my Garmin Etrex Venture Cx. I guess this is a recognizable state of > >> being, during a mapping session in urban canyons, walking around with > an > >> accuracy of 17 meters or more... > >> > >> I am looking for some sort of indication telling me, at which > time-of-day > >> there would be excellent conditions for creating tracks in a dense city > >> area. Has anybody come about such a service on the web yet? > >> > >> Currently I am not planning to upgrade on the hardware side, but do not > >> hesitate to suggest different makes, models or add-ons, which would > suffer > >> less from this urban canyon problem. > >> > >> Kind regards, > >> IvoM > >> > > > > IvoM, > > > > I think what you may be after is being able to predict date/times when > a) there is a good number of satellites in the sky around you so that your > GPS device can get as many readings as possible and choose the best, b) the > satellites are well distributed over the sky to help the mathematical > calculation of the GPS device and so that they are not all blocked by a tall > building at the same time. > > > > If so, try typing into Google: GPS Satellite predictor > > > > I came up with > > > > > https://stellarsupport.deere.com/stellar/SatellitePredictor?language=en&country=US > > > > If I remember, http://sirius.chinalake.navy.mil/satpred/, is a good one, > but it is dead when I just checked it. > > > > Unfortunately, even that probably won't help that much with urban > canyoning - you'll probably have to do several runs and then tie it in with > Yahoo imagery if you are lucky enough to have it for your area. One tip, > I've got my best results having my GPS device mounted in a bicycle > saddle-bag - it provides a much more stable platform than walking. And if > you are walking and your device loses satellite connection, put it on a > metal surface - a man-hole cover, traffic-signal controllers, even large > waste-paper bins. It seems to act as a ground-plane which improves the > antenna gain. > I have an external antenna, which has a magnet. When I stick it to the > frame of the bus or even the toddler's stroller/buggy, reception > increases dramatically. Could this be the same effect, or did I simply > increase the size of the antenna? > > Polyglot > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [EMAIL PROTECTED] memory issues ?
Just so it's 'recorded somewhere' ;-) I resolved this - I needed more than 4GB of memory, I added another 4GB of swap (3GB real memory, 5GB swap) and the tile generated. cheers On Dec 28, 2007 7:37 AM, Franc Carter <[EMAIL PROTECTED]> wrote: > > Hi, > > I've just upgraded my main machine to 3GB of RAM and put > a new the latest version of tilesAtHome (Linux) to try to do > some rendering - The centre of Sydney (3768,2458) bombs > out with what looks like a memory issue:- > > Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS > > Any ideas on what's wrong ? > > thanks > > -- > Franc -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] source=yahoo
I have seen these two source=Yahoo Imagery source=yahoo_imagery I'd be interested in knowing which is the more generally accepted one. cheers On Jan 10, 2008 7:12 AM, Lukasz Stelmach <[EMAIL PROTECTED]> wrote: > Greetings Everyone. > > If there is source=landsat for features derived from landsat photos > should I tag source=yahoo those ones I have spotted on Yahoo imagery? > > > -- > Best regards. Czwarta pospolita klęska, [...] > >Łukasz< Już nie katolicka lecz złodziejska. (c)PP > > > > -- > Nadchodzi wojna miedzygalaktyczna! > Sprawdz! >>> http://link.interia.pl/f1cc2 > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] source=yahoo
I swapped to this recently as well - on the basis of it being more 'consistent' with other tags - i.e lower case and no spaces cheers On Jan 10, 2008 10:31 AM, Lukasz Stelmach <[EMAIL PROTECTED]> wrote: > Franc Carter wrote: > > > > I have seen these two > > source=Yahoo Imagery > > source=yahoo_imagery > > the latter seems quite nice. i'll use it. > > > -- > Było mi bardzo miło. Czwarta pospolita klęska, [...] > >Łukasz< Już nie katolicka lecz złodziejska. (c)PP > > > > -- > Kupujesz laptopa? Sprawdz nasze testy! > Kliknij >>> http://link.interia.pl/f1cd1 > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] josm 'move sensitivity'
Hi, I just upgraded josm after 'sometime' and the amount of distance I have to drag a node befre it will move has increased - I can't find a setting to change this, am I being blind ? thanks -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] josm 'move sensitivity'
Excellent - config options are a good thing ;-) thanks On Fri, Feb 22, 2008 at 8:20 PM, Francisco R. Santos <[EMAIL PROTECTED]> wrote: > Hi Franc > > Yes, I had to reconfigure it, changing the threshold from 15 to 5 pixels > to make it work smooth (edit.initial-move-threshold=5). Look at this > thread: > > http://lists.openstreetmap.org/pipermail/josm-dev/2008-January/000656.html > > Regards, > Quico > > On Fri, Feb 22, 2008 at 8:18 AM, Franc Carter <[EMAIL PROTECTED]> > wrote: > > > > > Hi, > > > > I just upgraded josm after 'sometime' and the amount of distance I have > > to drag > > a node befre it will move has increased - I can't find a setting to > > change this, > > am I being blind ? > > > > thanks > > > > -- > > Franc > > ___ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > > > > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] oneway except bicyckes
thanks On Wed, Mar 12, 2008 at 8:59 PM, Michael Collinson <[EMAIL PROTECTED]> wrote: > At 10:51 AM 3/12/2008, Franc Carter wrote: > > >What's the best way to tag a piece of road that is oneway except for > >bicycles ? > > oneway=yes > cycleway=opposite > > OR if there is a marked lane for bicycles: > > oneway=yes > cycleway=opposite_lane > > http://wiki.openstreetmap.org/index.php/Map_Features#Cycleway > > Mike > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] oneway except bicyckes
Hi, What's the best way to tag a piece of road that is oneway except for bicycles ? thanks -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
On Fri, Mar 28, 2008 at 10:37 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > Hi, > > just to give you a quick overview about recent changes in JOSM > (some of them will only apply after tonight's automatic build): > > * Scale has been fixed, now displays correct value and has some > "ticks" for better reading. However, I have not forced the scale > to round values because this would mean that it would wiggle while > zooming in and out. > > * Tagging presets have been changed to take existing settings into > account, i.e. when you go to a preset panel for "roads" and have > some roads already selected, only those values that you explicitly > change will be changed. If you have multiple items selected with > incompatible values, the well-known "" will appear. This > feature is still a bit experimental, most notably because I had to > introdue a quad-state checkbox for it to work... tell me if it > works for you or if you want it different. > > * It is now possible to have arrows on the lines connecting GPS > points (draw.rawgps.direction=true), and you can also limit the > length of these GPS connection lines (draw.rawgps.max-line-length=x, > in metres), for those cases where you get crazy zig-zagging. Caveat > emptor, using the max-line-length option will slow things down a > bit. These config options have to be set manually (via the > expert preferences panel or with a text editor in the preferences > file). Fantastic - I'm going to find this incredibly useful for oneways and knowing which direction I was going when I took a photo. cheers > > > Bye > Frederik > > -- > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Unknown road classifications
Back when I started OSMing, I came across the tag 'complete=no', so this is what I tend to use On Mon, May 12, 2008 at 6:38 PM, Steve Hill <[EMAIL PROTECTED]> wrote: > On Sun, 11 May 2008, Jeffrey Martin wrote: > > > Did we ever decide what to do when a road continues but > > we didn't continue down the road? > > I tend to do "fixme=Road continues" or "fixme=Footway continues". > Although to be honest, in most cases for roads I either follow them as far > as they go (when I am doing real OSM surveying), or I am just collecting a > track as I drive on some other business so I don't get any detail other > than the road's position (and thus won't know if the road continues when I > review the track later). > > - Steve >xmpp:[EMAIL PROTECTED] <[EMAIL PROTECTED]> > sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> http://www.nexusuk.org/ > > Servatis a periculum, servatis a maleficum - Whisper, Evanescence > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Using Osmarender to hilight Relation/Routes?
Hi Frederick, did you manage to put something together that renders turn restrictions ? I'm interested in anything you have that does that. cheers On Fri, May 16, 2008 at 6:24 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > Hi, > > > Sort of like the previously feature image: > > http://wiki.openstreetmap.org/index.php/Image:Cyclingnodes.jpg > > > > I spent a while poking around the Wiki and trying to understand the > > XSL source (not my forte), but am still none the wiser. Anyone got > > any hints/clues for me? > > I was in a similar situation because I wanted to display turn > restriction relations on the map; not properly understanding XSL made > me then implement Osmarender in Perl (the "orp" directory in SVN). It > more or less does everything exactly the same as Osmarender does, just > without XSL. I haven't got round to do it yet but putting in some > code/rules there for rendering relations should not be too difficult. > > (For those with XSLT knowledge it should not be too difficult to add > the the Osmarender XSL but I didn't want to go there.) > > Bye > Frederik > > -- > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
