Re: [Imports] WiFi Hotspots in SA

Definitely this is the type of thing you want to pop up and say: You just connected to a hotspot: none is in the database, add it? Then have the user drag it to just the right spot, and add metadata: * Open/Password/Open With Confirmation Screen * Free/Pay/Customers Only * Speedtest

Re: [Imports] OSM Import Question

Note that tools exist to help with ongoing conflation/synchronization. Overwriting data entered by hand is a general OSM third rail topic. However, a script that creates a list of "things to check" or "mismatches" has a welcome home: for example it can become a "maproulette" job, where a human come

Re: [Imports] OSM Import Question

On Thu, Aug 27, 2015 at 8:56 AM, Jim Stob wrote: > Hello OSM Community, > > My name is Jim Stob and I am with Position Technologies, Inc. Position > Tech works with large North America brands in managing their brick and > mortar locations within the local ecosystem. We work closely with engines >

Re: [Imports] Undiscussed mass-edit of amenity=fire_hydrant => emergency=fire_hydrant

If that move was discussed, and if the two phases were separated by a good period like 3 months, I'd support the edit. ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Form of written consent for an import?

On Thu, Jun 11, 2015 at 12:55 AM, Robert Buchholz wrote: > I contacted the holder of rights for the 3D model asking them whether they > would allow import to OSM. They verbally gave their consent, and are asking > me how to proceed, i.e. in which form they should give their consent in > writing.

[Imports] Proposed mechanical edit for comment: amenity=ev_charging

109 uses of http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dev_charging remain, though http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station has long since taken over. The proposed edit will move over the nodes that make sense, and completely remove *amenity=ev_charging* from the data

Re: [Imports] Harmful elements in taginfo tag cleanup process

Eventually, I feel the project will need to move to either a reputation system (where others rate the quality of edits) or a double approval system (where a second mapper must endorse an edit before it goes live -- perhaps only for edits that remove information). -- If you have a tag that's common

[Imports] Proposed mechanical edit: waterway=water_point

For your comment: http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_Nesbitt#PROPOSED_--_waterway.3Dwater_point This should be fairly straightforward. In part because of a wiki error, waterway=water_point was used to describe places a motorhome can fill tanks. This proposed edit will ex

Re: [Imports] Proposed import removal: nuclear explosion sites

On Fri, Apr 17, 2015 at 12:11 PM, Martin Koppenhoefer < dieterdre...@gmail.com> wrote: > > Am 17.04.2015 um 19:33 schrieb Bryce Nesbitt : > > In all cases the argument that "some barely-detectable trace > archaeological remnant remains" seems to be thin justificati

Re: [Imports] Proposed import removal: nuclear explosion sites

There's an insane disconnect between this discussion about keeping nuclear explosion events, and the one about removing railways. The argument seems to come down to what was left over and if it's mappable. Well, the two are very similar: * Nuclear explosions leave craters and radioactive isotopes

Re: [Imports] Proposed import removal: nuclear explosion sites

On Wed, Apr 15, 2015 at 7:09 AM, Pavel Machek wrote: > I agree. It does not cause any problems to keep this data, and it is > very small data set. Just keep it. I think this illustrates the point that it's very easy to add questionable or low quality data to OSM, and very hard to gain consensus t

Re: [Imports] Proposed import removal: nuclear explosion sites

On Tue, Apr 14, 2015 at 1:56 PM, Martin Koppenhoefer wrote: > > I agree that this tag is on the borderline, but I plea to keep it for the > reasons I mentioned before, I think they are an interesting piece in the > map that is a significant part in the whole picture > > cheers > Martin I think

Re: [Imports] [Talk-us] Importing Tesla Superchargers

On Mon, Apr 13, 2015 at 7:30 PM, Charles Samuels wrote: > On Monday, April 13, 2015 05:01:39 PM Bryce Nesbitt wrote: > > You'll need to call someone at Tesla to get a better answer: an email has > > only a low chance of getting a response. > > what department do you su

Re: [Imports] Proposed import removal: nuclear explosion sites

+1 I think this import should go. It leads down a road to mapping things like past music concerts (they leave trash, right, just like radioactive fallout?). It's not a map feature, unless there is a memorial, crater, hazard, or some other present day expression of the past event. In which case map

Re: [Imports] [Talk-us] Importing Tesla Superchargers

On Mon, Apr 13, 2015 at 4:11 PM, Charles Samuels wrote: > > I'll see those in the changesets I produce. > No, as you've described your process, you won't see those OSM mapper changes at all, because they won't show up in your overpass query. You're jumping into an area with some history in OSM,

Re: [Imports] [Talk-us] Importing Tesla Superchargers

On Fri, Apr 10, 2015 at 11:28 PM, Charles Samuels wrote: > > -- Forwarded message -- > From: Keith Winkler > To: Charles Samuels > Cc: > Date: Fri, 10 Apr 2015 13:00:52 -0500 > Subject: Re: Importing into OpenStreetMap > Greetings Charles. > > Sure, no problem. > > I indeed have

Re: [Imports] [Talk-us] Importing Tesla Superchargers

Having done a few "up to dating" scripts: I recommend looking for nearby amenity=charging_station, not name= Supercharger. In fact you may want to make this even more "fuzzy", checking for either tag. And use name:Supercharger not name=Supercharger. OSM mappers will often change things like a na

Re: [Imports] Using shp2osm

shp2osm looks like it was last updated in 2009. While you could manually fix the output pretty easy, maybe these are better for your needs: http://wiki.openstreetmap.org/wiki/Import/Shapefile#Advanced:_Conversion_tools Note that many GIS layers are not a good match for OSM import, but, with care

Re: [Imports] [OSM-talk] PD: what can I do with automatic changes done against code of conduct

The general answer is that if you have a disagreement with another mapper, try in order: 1. Contact and engage with that mapper via notes on the changeset (or better yet) a private message via the OSM message system. 2. Write to your local or national mailing list. Again at this point

Re: [Imports] Mechanical Tagging Proposal - dump_station - conditional

On Wed, Apr 1, 2015 at 9:34 AM, Andy Allan wrote: > On 1 April 2015 at 17:21, Bryce Nesbitt wrote: > > > The main downside however is that recycling:excrement=yes/no is one of > the > tagging methods that currently renders. > > Retagging will cause the feature not to

Re: [Imports] Mechanical Tagging Proposal - dump_station - conditional

stylesheet. On 18/03/2015 20:21, Bryce Nesbitt wrote: > For your comment is the following proposal is to consolidate sanitary dump > station tagging semi-mechanically: > http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_ > Nesbitt#DISCUSSION_--_Sanitary_Stati

Re: [Imports] [Talk-us] Tesla Supercharger import

On Sat, Mar 28, 2015 at 11:40 PM, Charles Samuels wrote: > > I am not subscribed to "imports", please CC me directly. > To engage in the process fully, you'll need to subscribe. > I have not yet asked Tesla Motors for their permission, I have a hard time > believing it'd be refused. > Let us

Re: [Imports] Unsure if this import is pure spam, or just part spam : OCHA Colombia 2010

Because it looks like an attempt to advertise the medical billing software, I have not made contact. It has "http://"; which makes it unlikely to be an attempt to put an email address in. The import is thousands of nodes, and from the year 2010. On Sat, Mar 28, 2015 at 8:05 AM, Clifford Snow wr

[Imports] Unsure if this import is pure spam, or just part spam : OCHA Colombia 2010

I ended up on node 703199344 which has a "set better denotation" tag on a hamlet. But the website link caught my eye. An overpass search shows quite a number of links to this particular website, which I won't name in full: node["comment"~"GaleNUx"]({{bbox}}); The "OCHA Colombia 2010" import its

Re: [Imports] Mechanical Tagging Proposal - dump_station - conditional

I'm starting this process now. ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Mechanical Tagging Proposal - dump_station - conditional

Second call for comments on semi-mechanically harmonizing dump station tagging, conditional on the wiki approval process. http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_Nesbitt#DISCUSSION_--_Sanitary_Station_Retagging ___ Imports mailing list

Re: [Imports] For comment: import of 532 bicycle repair station locations

On Fri, Mar 20, 2015 at 2:11 AM, Michal Palenik wrote: > what about service:bicycle:diy = 'yes' ? > That's a reasonable tag to add to a bicycle shop that offers Do It Yourself tool access. But often those rules are complicated. For example my local bike shop offers full access to their shop, b

Re: [Imports] For comment: import of 532 bicycle repair station locations

ir_tools* might have been less confusing. On Thu, Jan 22, 2015 at 9:55 PM, Paul Norman wrote: > On 1/22/2015 2:27 PM, Bryce Nesbitt wrote: > > For your comment: > > https://wiki.openstreetmap.org/wiki/Import/Dero_Bike_Repair > > > This is an interesting proposal >

Re: [Imports] eHealth Africa Borno Smaller Settlements Import and Road Editing

I think the concerns are: 1) Will each mapper use the same keys, and if they misspell something, will that be caught? 2) How will future updates be "conflated" or brought into OSM? 3) Will duplicates be caught (data already in OSM)? 4) What tags and values, specifically, will be part of this impor

Re: [Imports] eHealth Africa Borno Smaller Settlements Import and Road Editing

The NGO updates data, and corrects a hamlet name, how will that change flow to Open Street Map? How will those objects be "conflated"? -- A problem I see with imports like this is that each mapper uses slightly different tags. Part of this is a language issue. What will keep people from alteri

Re: [Imports] Mechanical Tagging Proposal - dump_station - conditional

On Wed, Mar 18, 2015 at 2:43 PM, SomeoneElse wrote: > On 18/03/2015 20:21, Bryce Nesbitt wrote: > >> For your comment is the following proposal is to consolidate sanitary >> dump station tagging semi-mechanically: >> http://wiki.openstreetmap.org/wiki/Mechanical_E

[Imports] Mechanical Tagging Proposal - dump_station - conditional

For your comment is the following proposal is to consolidate sanitary dump station tagging semi-mechanically: http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_Nesbitt#DISCUSSION_--_Sanitary_Station_Retagging ___ Imports mailing list Imports@ope

Re: [Imports] eHealth Africa Borno Smaller Settlements Import and Road Editing

A sample sample is: place=hamlet name=Fooble taga=Fum tagb=Fum tacg=Fooble Keeping the actions of 80 people consistent is difficult, as past similar mapping efforts have shown. - Past history with "fixme" notes imported is not so good. Keep in mind a fixme is seen only by a person already

Re: [Imports] eHealth Africa Borno Smaller Settlements Import and Road Editing

I'd like to see some example data: three or four typical hamlets converted with GPS coordinates. I feel the imported "fixme" is more harm than good in this case. The flaw, if any, int the data is obvious to an on the ground mapper, and useless to an armchair mapper. The changeset references the

Re: [Imports] [Tagging] Resubmitted proposal: mechanically removing all denotation=cluster and fixme=set_better_denotation tags worldwide

On Fri, Mar 13, 2015 at 2:41 AM, Mateusz Konieczny wrote: > I am confused by "No human entered fixme values will be harmed." in > description and "removing all (...)" in the title. > The "fixme" tags added by the tree bot are proposed for bulk deletion without additional review. Other "fixme" no

[Imports] Resubmitted proposal: mechanically removing all denotation=cluster and fixme=set_better_denotation tags worldwide

Resubmitting by request of maper Sly: The edit described at http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_Nesbitt was modified based on mailing list input, and sits at complete removal of the "cluster" value for denotation, along with a certain fixme value. The "cluster" value was i

Re: [Imports] [OSM-talk] [Talk-de] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

On Tue, Mar 10, 2015 at 3:11 PM, sly (sylvain letuffe) wrote: > Le mardi 10 mars 2015 22:14:45, Bryce Nesbitt a écrit : > It isn't really clear to me what you mean by that, but I don't like mixing > different changeset types of mechanical edits. It makes it harder to > u

Re: [Imports] Import of ehealthafrica.org Borno state residential areas and partial correction of wards and lgas boundaries

You write "eHealth Africa has given full authorization for their data with the standard authorization document of the HOT ". Could you link to that authorization, upload a copy, or otherwise document the authorization? ___ I

Re: [Imports] [OSM-talk] [Talk-de] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

I'm writing with a proposed extension to this mechanical edit: adjusting the type and wood tags to current conventions. It's easy to do and saves future changeset churn. I'm also adding "denoation=historic" on certain trees, and removing "denotation=cluster" from things like water towers. ___

Re: [Imports] [OSM-talk] [Talk-de] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

On Thu, Mar 5, 2015 at 2:40 PM, Bryce Nesbitt wrote: > Ok, call for additional perhaps final comments on this worldwide > mechanical cleanup for the impacts of the denotation=cluster import. > Fire in the hole: the first changeset is

Re: [Imports] [OSM-talk] [Talk-de] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

Ok, call for additional perhaps final comments on this worldwide mechanical cleanup for the impacts of the denotation=cluster import. ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] For comment: import of amenity=bicycle_repair_stations

On Wed, Mar 4, 2015 at 9:34 PM, an UK mapper wrote wrote: > Way back when, Bryce wrote: > > The locations need local mapping to get the location perfect. > > Are you intending to feed these local changes back to the data source? > Will the import involve deleting any repair stations in OSM not in t

Re: [Imports] fleet manager speed reports

On Wed, Mar 4, 2015 at 12:10 PM, Richard Weait wrote: > This isn't a perfect maproulette challenge, either, because it can't > be confirmed by aerial imagery with remote contributors. Ideally, you > should have local knowledge. This in fact would seem better able to connect with local uses via

Re: [Imports] fleet manager speed reports

In my work with a different fleet management firm, the questions of speed limit are often resolved through use of a forward facing driver camera. The video from the same camera is used to resolve other alerts (fast stops/starts, tight turns, bumps, backing up (a highly restricted activity in certai

Re: [Imports] [OSM-talk] [Talk-de] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

Ok, making a possibly final call for input on the proposed "cluster" mechanical edit: http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_Nesbitt ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

[Imports] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

This is now a formal proposal to mechanically remove: denotation=cluster fixme=set␣better␣denotation >From 200,000+ nodes. See http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_Nesbitt The original mapper has commented on this proposal: *The fixmes are useless and can be delet

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

On Fri, Feb 27, 2015 at 9:04 AM, moltonel 3x Combo wrote: > > On 27/02/2015, Christoph Hormann wrote: > > fixme=stream␣attributes␣missing > > fixme=stream␣attribute␣data␣missing > > > > have not been added by an import but in an attempt to fix a broken > > import. There seems to have been a sim

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

To make this simpler, for now I propose to mechanically delete the tags: fixme=stream␣attibutes␣missing stream=fixme >From several stream imports in the USA. Does anyone have comment or considerations for that proposal (beyond the usual mechanical edit policy)? _

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

On Thu, Feb 26, 2015 at 3:55 PM, Blake Girardot wrote: > I am strongly in this camp. I have not seen any actual harm or problem > presented for 1.3 million fixme tags yet. But there is the potential for > problems if removed. > Even fixme=yes tags convey information: Someone felt something was in

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

On Thu, Feb 26, 2015 at 1:16 PM, Greg Troxel wrote: > > I think part of the objection to mechanical removal is that just because > there are a lot of particular values doesn't mean they are all junk, and > some could well have been added by hand. > > Perhaps a more limited cleanup that removes fi

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

Here's an example semi-bulk FIXME cleanup just done. This was manual, not script based: http://www.openstreetmap.org/changeset/29107328 Clearly this was a simple mistake (a JOSM user doing "select all" and getting nodes in addition to the ways they wanted to target). The original changeset was:

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

On Wed, Feb 25, 2015 at 9:57 AM, Jonathan Bennett wrote: > > Actually I think you've misunderstood: > > You've said these are Junk Tags, and I think everyone has agreed with > you on that. However people have also pointed out that they are probably > attached to Junk Data. How about if I summari

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

fixme=yes is an interesting one socially. It's a bit like tiger:reviewed=no If there's an obvious problem, I might feel confident to fix the issue and clear the tag out. But for most nodes I might be unsure what's wrong, or not be confident I know 100% about the object. Thus the fixme=yes sits th

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

It's also possible to turn some of those like "could_be_dunes_or_beach" into notes, rather than FIXME. ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [OSM-talk] Mechanically Cleaning Up FIXME Tags

Any fixme in wide use I'm not interested in deleting. Get rid: fixme=check/adjust␣position␣and/or␣merge␣with␣existing␣stop␣if␣exists fixme=type_of_palm fixme=imported_to_be_checked FIXME=stream␣attribute␣data␣missing Keep: fixme=continue fixme=position fixme=resurvey fixme=dual_carriageway Speak

[Imports] Mechanically Cleaning Up FIXME Tags

I'm opening a discussion about a potential mechanical edit to FIXME tags: http://taginfo.openstreetmap.org/keys/fixme#values http://taginfo.openstreetmap.org/keys/FIXME#values It is apparent that a number of imports have left tens of thousands of fixme notes that have a low chance of ever getting

Re: [Imports] For comment: import of amenity=bicycle_repair_stations

, Feb 21, 2015 at 9:41 AM, Bryce Nesbitt wrote: > I'm ready to start this import: the input to date has been carefully > considered and adjustments made. > > I'm intending to add notes for locations where the press releases are > insufficiently specific to correctly position

Re: [Imports] Importing names of homeowners : Nepal Red Cross

There are a lot of offending tags: chicken count is high on my list. And the toilets: private toilets don't belong, unless the owners of the hut really intend to invite hikers in. This seems to be a common theme among developing country / HOT mappers to catalog and map the contents of non-public b

[Imports] Importing names of homeowners : Nepal Red Cross

I noticed an import today that brings up some issues and a general principle. Here's a sample node: https://www.openstreetmap.org/way/311684106 Note it contains the name of the owner of the building, and the count of chickens they own. The general principle is that readily outdated data is perhap

Re: [Imports] Update of german Aral petrol stations

On Wed, Feb 18, 2015 at 5:04 AM, Bas van Kempen wrote: > Thanks for thinking of a solution with us. > > > > When referring to Avia, I meant Avia International (fuel retail): > http://www.avia-international.com/ > > > > I definitely agree that the most useful POI’s are those for tourists > (hotel

Re: [Imports] Update of german Aral petrol stations

What about the case where the station changed owners, and is currently "brand=Something Else"? How will those match up? ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

On Sun, Feb 8, 2015 at 9:23 AM, Serge Wroclawski wrote: > Bryce, > > After reading through this thread, I just don't see this dataset as > being high enough of quality to import. > > Arguing that users will be free to move objects does not jive with the > ~10 years experience we have in OSM, and

Re: [Imports] For comment: import of amenity=bicycle_repair_stations

On Wed, Feb 11, 2015 at 3:36 PM, Greg Morgan wrote: > On Wed, Feb 11, 2015 at 2:23 PM, Bryce Nesbitt wrote: > > On Tue, Feb 10, 2015 at 5:04 PM, Greg Morgan wrote: > > > > > > Thanks for sharing your mapping project. > > > Regards, > > > Greg > &

Re: [Imports] Update of german Aral petrol stations

On Wed, Feb 11, 2015 at 10:30 PM, Seven (aka Arnulf) wrote: > Bryce, > thanks for the hints, these are all good points an I believe we can > proceed accordingly for this import/update. We will document in the > Wiki once we have a better understanding of how many stations are at > affected by the

Re: [Imports] Update of german Aral petrol stations

On Wed, Feb 11, 2015 at 7:21 AM, Knut Büscher wrote: > > *W**hat are we doing?* > The goal is to match OSM's existing german Aral petrol stations with the > latest data made available by the petrol station operator, then add missing > petrol stations and add additional tags to existing stations. T

Re: [Imports] Importing official Buildings/Addresses in Louisville KY

On Tue, Feb 10, 2015 at 1:04 PM, Paul Norman wrote: > On 2/10/2015 1:00 PM, Michael Schnuerle wrote: > >> For updatability, we will be adding a unique ID that comes from the >> source data and will remain the same in updates. But really any other >> updated data will be imported using this same m

Re: [Imports] Proposed import of South Australian waterbodies data

On Sun, Feb 8, 2015 at 3:59 PM, Henry Haselgrove wrote: > > > Your selection of 10k features from 150k total is not clear to > me. Why these 10k and do you plan to also import the rest later? > > I only have very tentative plans for the rest at the moment. It is an > enormous amount of d

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

Here's a list someone put together from press releases: https://bicycletrax.wordpress.com/2014/06/20/campuses-with-the-most-bike-repair-stations/ ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

On Sun, Feb 8, 2015 at 10:53 AM, Jo wrote: > Concerning the 1 I added in my hometown in Belgium. I never got an answer > from the organisation that installed it about the 2 other ones they had > planned. > I've found that the press releases for installation are not always followed up on. For ex

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

There are two mapped stations on the campus of TU Delft, in Belgium: http://www.dero.com/fixitmap/fixitmap.html If someone at TU Delft can be found to check on these, that would be great. To do it the OSM way, perhaps a map note? On Sun, Feb 8, 2015 at 9:44 AM, Jo wrote: > Are there any of thes

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

On Sun, Feb 8, 2015 at 9:23 AM, Serge Wroclawski wrote: > Bryce, > > After reading through this thread, I just don't see this dataset as > being high enough of quality to import. > I see it as a great quality dataset : more than sufficient to locate the given feature on the ground. Note that so

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

On Sun, Feb 8, 2015 at 8:23 AM, Greg Troxel wrote: > > 40m seems too close for fuzzy matching, or rather I think you need two > thresholds. I would think that you'd want something like 250m to flag > it as sort-of-matching for human review. 250m is slightly too large, as several campus install

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

Are there any additional comments on the issue of importing (actually synchronizing) 500 bicycle repair stations? With this import OSM would become the most comprehensive database of repair station locations. To summarize: the import database is maintained by a vendor of bicycle repair stations, t

Re: [Imports] For comment: import of 532 bicycle repair station locations

On Mon, Jan 26, 2015 at 10:33 PM, Paul Norman wrote: > On 1/26/2015 10:24 PM, Bryce Nesbitt wrote: > >> Here's the full list of stations for import. >> Have a look in your area, see how they match up: >> https://www.dropbox.com/s/d5za49eptco3y0c/osmsync_ccs2.osm?dl=0

Re: [Imports] For comment: import of 532 bicycle repair station locations

Here's the full list of stations for import. Have a look in your area, see how they match up: https://www.dropbox.com/s/d5za49eptco3y0c/osmsync_ccs2.osm?dl=0 Armchair mapping won't be much help though (unless you are with a high power spy agency): these stations are only 4 inches in diameter. Note

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

On Mon, Jan 26, 2015 at 2:40 PM, Greg Troxel wrote: > > Also, if a tag isn't rendered in the default mapnik view, then those > elements are unlikely to be cleaned up (absent a special render for a > community of interest, which the cyclemap layer might be). > It's a chicken and egg situation. Wi

Re: [Imports] [OSM-talk] amenity=bicycle_repair_station :::: only 18 so far

On Mon, Jan 26, 2015 at 1:13 AM, Philip Barnes wrote: > On Mon Jan 26 07:37:57 2015 GMT, Bryce Nesbitt wrote: > > > >> The locations I field checked were all findable, but had positioning > errors > >> consistent with smartphone GPS units, > >> up to 30 m

Re: [Imports] For comment: import of 532 bicycle repair station locations

On Sun, Jan 25, 2015 at 2:06 PM, Ethan Nelson wrote: > Hi Bryce, > Could you elaborate a bit more on the data collection process? How is the > location data retrieved...GPS only or cell network-based tracking as well? > Is the uncertainty/error in the measurement included? Also, is the data > ma

Re: [Imports] For comment: import of 532 bicycle repair station locations

Note that amenity=bicycle_repair_station is not rendered anywhere, and is only supported as a preset in JOSM and iD. People have been doing wacky things to get these to render in the past: * amenity=bicycle_parking with a capacity of zero * tourism=information * shop=bicycle with tags indica

Re: [Imports] For comment: import of 532 bicycle repair station locations

> It would be good to get something on the record from Dero that the license is ODbL, either an email or something public would work. Per my proposal to Dero, the ODbL statement was embedded the map source code at http://www.dero.com/fixitmap/fixitmap.html That counts as public, makes the backing

[Imports] For comment: import of 532 bicycle repair station locations worldwide

For your comment: https://wiki.openstreetmap.org/wiki/Import/Dero_Bike_Repair This is a global import, though skewed to the USA. ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

[Imports] For comment: import of 532 bicycle repair station locations

For your comment: https://wiki.openstreetmap.org/wiki/Import/Dero_Bike_Repair ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] [tl; dr] Re: cleanup broken import "fix"

> do you have a complete list of the tags that you propose to "drop"? > gnis:id=* 6577 > gnis:state_id=* 26 > gnis:fcode=* > nhd:com_id=*56793 > nhd:fdate=* 56793 > Reasoning: there is no use in these tags. There is a strong an compelling use for the G

Re: [Imports] [Imports-us] "fleet manager" speed limit import proposal (Canada, USA)

Keep in mind when collecting "fleet" speed limits: in many places HGV's have a different limit than other traffic. For example the Interstates in California USA are generally 65 mph general/55 mph trucks. ___ Imports mailing list Imports@openstreetmap.or

Re: [Imports] Fwd: Nuovo Import

I encourage you to document the permission statement for the data, to use the gtfs data if available, and to preserve the primary key (or keys as the case may be) for each stop. Articulate how, two years from now, someone might check the data against whatever is new at the time. If the bus service

Re: [Imports] GNS tag cleanup

My comments largely revolve around the use of editor based deprecation. --- One comment is specific to GNS. The gns:uni and gns:ufi are a primary keys in the source data, and as such should definitely be kept to aid in future matching or conflation of the object. See: http://www.geographic.org/g

Re: [Imports] Bulk import the POIs of worldwide chain of stores

There are not standard tools for this, and there are a variety of opinions on the topic. There are a few, mostly one off, tools for synchronization. An example is osmsync_noaa_nexrad.py ( http://svn.openstreetmap.org/imports/ongoing/osmsync_noaa_nexrad.py ) Which: 1. Loads http://www.ncdc.no

Re: [Imports] [osm-pl] Fwd: Re: Import of addresses in Poland

What I see increasingly happening is that local government geodatabases are getting better and better: to the point where it gets really hard to argue for using anything else. That's not every data set, and not every place. But it points to the tension:* 'Is OpenStreetMap meant to be made, or mea

[Imports] Proposed new section in import guidelines

This is a proposed additional topic for "Step 3" http://wiki.openstreetmap.org/wiki/Import/Guidelines The goal is to ask respondents to document something they probably are in a good position to find out:: How frequently has the source data been updated and by whom? And answer one questi

Re: [Imports] Import UNICEF data in Central African Republic, act II

NB: I've quite frequently uploaded changesets with a mix of sources. In fact it's typical. I'll upload a few gps tagged traces, tweak them based on the air photo and memory, then fix up a few other things while I'm in the area. A mix of armchair and on the ground mapping in every change set. (If

Re: [Imports] Consensus call Re: Import UNICEF data in Central African Republic, act II

While I feel the proposed import would be stronger if it defined a plan for future updates, it seems a relatively good and trouble free import operation. ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports

Re: [Imports] Import UNICEF data in Central African Republic, act II

On Sat, Jan 25, 2014 at 2:23 AM, Martin Koppenhoefer wrote: >> Am 25/gen/2014 um 10:05 schrieb Bryce Nesbitt : >> I would leave the source=Unicef tag in place. > > most mappers do this, that's the reason why you can't trust source tags on > objects ;-) > cheers

Re: [Imports] Import UNICEF data in Central African Republic, act II

On Sat, Jan 25, 2014 at 12:29 AM, Martin Koppenhoefer wrote: > 2014/1/25 Bryce Nesbitt >> >> I think that "source=UNICEF" very much belongs on each imported >> record, as a mapper I would appreciate seeing that while editing. > > and what would you do to thi

Re: [Imports] Import UNICEF data in Central African Republic, act II

I think that "source=UNICEF" very much belongs on each imported record, as a mapper I would appreciate seeing that while editing. Additional details including the URL belong on the changeset (as you have done). I would prefer to see the FOSA_CODE or ID set as "source:pkey" as a future fuzzy for up

Re: [Imports] [Imports-us] Address Data Import for Fulton County, Georgia

The issue of 'source attribution' is one that comes up over and over again. Having a good standard answer to that would be nice. I think OSM should tag the contributing source in a way that would allow any region to be selected, and show a list of contributors, be they OSM users, background map pr

Re: [Imports] Zaatari Imports

The difficulty with things like unosat:event_code is that they could well look like "junk" to a future mapper. "source" and "source:pkey" are perhaps better, a little more transparent in terms of intent. Some mappers object to storing external primary key data in OSM objects. Personally I think i

[Imports] UNHCR Jordan Import

FYI: there's an import that could use some additional eyes: http://wiki.openstreetmap.org/wiki/REACH_Camp_Mapping http://www.openstreetmap.org/browse/changeset/16693954 I spotted it after seeing some inexplicable values for toilets over at: http://taginfo.openstreetmap.org/keys/toilets:disposal#va

Re: [Imports] NYC building and address import

On Mon, Sep 16, 2013 at 8:39 AM, Alex Barth wrote: > Bryce - > On Fri, Sep 13, 2013 at 9:28 PM, Bryce Nesbitt wrote: > >> Around the same time I looked into importing the NYC drinking fountain >> data into OSM. However after reading the licence, >> > The Local La

Re: [Imports] NYC building and address import

On Tue, Sep 10, 2013 at 5:22 AM, Alex Barth wrote: > I'm submitting this import proposal for peer review on this list: > https://github.com/osmlab/nycbuildings/blob/master/PROPOSAL.md > In March 2012, NYC has made all its data public. In the meantime we've > worked closely with the NYC governmen

Re: [Imports] Add to discard ist : more tiger tags

On Thu, Sep 12, 2013 at 3:42 PM, Andrew Buck wrote: > Hmm, regarding the ones not touched by the name expansion bot due to > prior user activity... is there a list of these way id's somewhere? > > It would be good to go over all of these systematically if there are > not too many of them and have

  1   2   >