2012/10/12 Fabien SK :
> I asked on the Wikipedia discussion page of the «Trains in Japan»
> project [1]. Someone told me that names (that is the only information I
> retrieved in Wikipedia) cannot copyrighted, so I should be able do to
> use them.
but you would also use the coordinates to the n
2012/10/12 Fabien SK :
> No I did not used the coordinates, only the names. The train stations
> already exist in Openstreetmap. In JOSM, I either:
> - manually download a train station having only a japanese name
> - download an area with train stations, or the members of a railway
> relationship
2012/10/29 Balázs Szalkai :
> More than about one third of Hungary has already been imported from the CLC
> dataset by others. The following tag is used for attribution:
> source=© EEA, Koppenhága (2009); Készítette a FÖMI a KvVM megbízásából
> (2009)
> I'm not a lawyer but I think this tagging is
2012/10/29 Balázs Szalkai :
> "I think the question about tagging was refering to how you translate
> the Corine-tags to OSM-tags, and which tags from Corine you translate
> and which you drop."
>
> Let me put it this way. Some guy in the past has already converted the CLC
> dataset to .osm. I don'
2012/11/5 László Csatlós :
> About CLC:id: We keep them because of the easier update and indentification
> later. It is not much work to delete them in a batch.
what is your recommendation how to deal with this when you modify the
object, e.g. split it in several parts, or when you combine severa
As a general note (you write some paragraphs about merging the
external dataset with the existing data in OSM) it would be nice to
have your importing procedure explicitly state that existing data
prevails and conflicts would ideally be resolved by survey.
You state that every single object will g
2012/11/21 Maurizio Daniele :
> Recently the Piedmont region (northwest of Italy) published a lot of data
> [1] under CC license, most of them are CC-BY 2.5, a few CC0, some others
> with different licenses we cannot use.
> So it did the city of Torino [2]
>
> A lot of these datas are interesting (
Am 24/dic/2012 um 15:58 schrieb Jeff Meyer :
> If individuals are reviewing small chunks of data at a time as part of a
> particular import process, and the import is not automated, should there
> still be a separate account?
The reason to require it nonetheless might be different intellec
2012/12/25 Frederik Ramm :
> On 12/24/2012 03:58 PM, Jeff Meyer wrote:
>> Again, it seems there needs to be a clearer definition of "import," as
>> not all imports are automated.
> I think it depends on the attitude of the person doing it.
> If the mapper says "today I'll map South Sometown and I'l
Am 15/gen/2013 um 08:22 schrieb Jaak Laineste :
> 3. Use natural capitalisation for street names, 'Catherine', not all caps
+1, also it looks from 5) as if the value for addr:street would be "Catherine
Street"
cheers,
Martin
___
Imports mailing l
2013/1/17 Cruz Enrique Borges :
> The first version exported too much data and created lots of relations
> so we've been working with spanish OSM community on a second version
> of Cat2Osm2 [2], that simplifies the result by losing some extra info
> like:
...
> - not taking in account building leve
Am 28/feb/2013 um 21:10 schrieb Cruz Enrique Borges Hernandez
:
>
> + Do not import these features.
+1, upload them after verification
cheers,
Martin
___
Imports mailing list
Imports@openstreetmap.org
http://lists.openstreetmap.org/listinfo/impo
Am 27/feb/2013 um 22:45 schrieb Sarah Hoffmann :
> The single building parts make not much
> sense for anything but 3D rendering. And I suspect that they are going to
> give you a big headache once you get around to mapping addresses.
building parts are fine, but they are not an alternative
Am 02/mar/2013 um 00:43 schrieb Paul Norman :
> The entrance=yes node won't be used for routing. If you have the address on
> the building, it will put you at the closest mapped road to the building
so you're proposing mapping for the routers because they currently don't
interpret entrance
Am 02/mar/2013 um 09:55 schrieb Paul Norman :
> If you don't know the height and are just estimating it from the number of
> floors, you shouldn't include a height tag.
+1, use building:levels (or similar) instead
cheers,
Martin
___
Imports maili
Am 05/mar/2013 um 15:41 schrieb Jochen Topf :
> We are also proposing to remove the huge natural=glacier multipolygon that
> covers large parts of Antarctica. It is quite unusual to tag the "default"
> land
> cover this way (there is no "desert" multipolygon covering half of North
> Africa
2013/3/12 Andy Allan :
> 3) If you're not using hillshading, inverse vs normal makes no visual
> difference. But as soon as you use hillshading, you want inverse. So
> all else being equal, inverse should be the default
if you're using bathymetry you'll want "normal" (land polygons). When
you're
On 05/mag/2013, at 09:30, "Jaak Laineste (Nutiteq)" wrote:
> I'd suggest not to use tags for default values (oneway=false,lanes=1,level=1
> etc), otherwise you may end up with a lot of paths with spam tags.
Generally agree, just wanted to point out that the default for lanes is mostly
as
On 05/mag/2013, at 12:28, Christoph Hormann wrote:
> 1) duplicate the way
> 2) tag natural=coastline;whatever
> 3) create a multipolygon relation containing a single way with natural=*
>
> I used option 3 but i could not find any definitive answer to this
> question so i will leave it open
2013/5/14 Christoph Hormann
> ADD:code -> (discard)
> ADD:text -> note
> ADD:revision -> source:date
> ADD:date -> survey:date
> ADD:source=* -> source=ADD;*
>
if source, date and revision are the same for all objects (or could be
grouped into changesets with identical values), they could be ta
On 16/mag/2013, at 10:35, "Christian Haeske" wrote:
> We have also the outlines of the places, but that would be overkill and we
> don´t want to import them since they have mostly no visual analogy.
they don't correspond with the borders that are mapped, like landuse=farmland?
It might be
2013/5/17 Christian Haeske
> The outlines come from the cadastral (property) map.
>
of course, that's what we are talking about
> There are 1 to 5 separate outlines per place, some are also really small.
> That would be too much detail, we don´t want to copy the property map to
> osm so we w
I have found this research station which isn't in the new ADD data (section
23, at least not at the same position), is this expected?
http://www.openstreetmap.org/browse/node/2012557572
cheers,
Martin
___
Imports mailing list
Imports@openstreetmap.org
h
On 27/giu/2013, at 11:35, Stefano Martina wrote:
> Hi, I'm new to imports in OSM. I hastily imported all civic numbers of
> Florence in Italy from the opendata of the municipality without reading the
> guidelines. The result is good and useful, and the license of data is free.
> What can I
2013/7/9 David Riccitelli
>
> I understand now the matter about car=yes.
>
> Can you clarify the following:
> 1. shall we then remove the *car=yes* tag? (at least until the matter is
> clarified)
> 2. what considerations shall we make for the value of the *access* tag?
> Doesn't the *access* ta
2013/7/10 David Riccitelli :
Jason Remillard: >> - what happens if a mapper, merges the node onto a building
IMHO this is a mapping error. How would you be able afterwards to
distinguish the building from the charging station and tell to which
object the tags apply? E.g. tag name, tag start_date,
2013/7/10 David Riccitelli :
>> >> - what happens if a station is deleted from the source data
>> > Stations deleted from the source data, or marked as inactive (e.g.
>> > maintenance), will be removed from OSM.
>>
>> not sure if stations marked as inactive should be completely removed,
>> maybe be
2013/7/12 Thomas Hirsch
Summary:
>
> - CC-BY 3.0 no, attribution “Kartverket”, explicit permission also granted.
>
is attribution in the OSM wiki (and changeset comments) sufficient to
satisfy the obligations? Permanent attribution on object level cannot be
guaranteed.
> - Names will be
2013/7/12 Thomas Hirsch
> Spelling issues have a particular dimension in Norway, as dialects are
> encouraged. In a similar vein to street names above, a lake may take any of
> the suffixes -tjern, tjernet, tjønn, tjenn, tjønna, tjenna and possibly
> more, according to the mood and dialect of the
2013/7/12 Sophie Kate Salway
> Are you for or against data imports?
> What are the benefits and/or negatives of introducing imports into the OSM
> database?
> Do you think data imports engage the OSM user? If so, why?
> Do you think data imports affect the overall quality of OSM?
> With the intro
2013/7/31 David Riccitelli
> Dear all,
>
> Enel's *charging stations *import has been completed successfully
> yesterday. Data has been loaded using Enel's account (EnelSharing) with *
> changeset *17153423:
> http://www.openstreetmap.org/browse/changeset/17153423
>
> The import software has been
2013/8/12 Serge Wroclawski
>
> Won't MA be getting address data soon (in the next 6 months)?
>
> If so, I think that would be a great time to make those changes, when
> adding address data.
>
> But right now, I think the superfluous tags don't hurt anything, even
> if they're annoying.
>
>
+1, an
Am 08/set/2013 um 10:39 schrieb Serge Wroclawski :
> * Reclassify objects which are currently gnis but should be other
> datasets (non-gnis).
being derived from one data set or the other is not an osm classification. Our
strength is crowd sourced data collection and maintenance / update. All
2013/9/10 Alex Barth
> I'm submitting this import proposal for peer review on this list:
>
> https://github.com/osmlab/nycbuildings/blob/master/PROPOSAL.md
>
>
could you please set up a page in the OSM wiki so that there remains trace?
thank you,
Martin
PS: There is already this page in the wi
2013/9/11 Clifford Snow
> Also about the kml file, it is no different than shp files, just another
> format. The kml makes it easy to overlay with google maps. Question - what
> is the open source equivalent for overlaying on OSM?
>
kml is actually an OGC standard since 2008, so "despite" bein
2013/9/13 andrzej zaborowski
> Can you point to an example of such incorrect expansion by the earlier
> bot? There isn't really an ambiguity between Saint and Street because
> one is a prefix and the other a suffix.
>
> There is an ambiguity though between Saint and State for example,
> which is
2013/9/28 Jason Remillard
>
> - remove all of the massgis: tags from the natural=water ways in
> Massachusetts.
>
> - Use the massgis:PALIS_ID to look up the lake/pond names from MassGIS
> data table. Around 200 water bodies will get named as part of this
> process. The name tag if it exists, is
2013/9/28 Elliott Plack
> bus stops, in my experience, are hard to map in OSM and can clutter urban
> centers. I like to see people add routes though.
in my experience it is easy to map bus-stops (after all they are just a
node like many other POIs), it is much harder to map bus routes, becaus
I just got aware of an import done in February 2013, which seems it went
wrong (I wrote to the user and he told me that apparently the dataset
provided by a tier organization working with HOT team had a bad format or
wrong localization).
The node in question that caught my attention is this one:
h
2013/10/14 Alex Barth
> (This is BCC to tagg...@osm.org, conversation to happen on
> imports@openstreetmap.org.)
>
> At the NYC building and address import we're facing the following question:
>
> **In cases where there is one address point per building, should we merge
> the address information
2013/10/15 Pieren
> It's also harder to represent both on a map, excepted if you can go to
> high zoom levels.
>
you can't show housenumbers in low zoom levels anyway.
> When we place the housenumber on one side of the
> building, everyone is intuitively understanding that this side is
> whe
2013/10/15 Alex Barth
> Re: source tag. We decided against it as the import is identified by
> import account and changeset comment.
>
> I don't find source tags useful in a database that routinely sources
> information for a single entity from multiple sources. I. e. what's the
> source tag for
2013/10/15 Pieren
> So, instead of changing a changeset tag, contributors will have to
> swap credentials in JOSM each time they use a different source... Of
> course, they will not do this for every small upload and we cannot
> rely on the user account suffix. The source tag is not 100% reliable
2013/10/16 Christoph Hormann
> > I've noticed that somebody recently added a rule to distinguish
> > waterway=river from waterway=stream on the wiki page for stream, but
> > I'm not sure how/where that rule (which is related to how far an able
> > person can jump) became commonly accepted?
>
> I
> Am 16/ott/2013 um 22:28 schrieb Christoph Hormann :
>
> My interpretation always was that it means where an able person can and
> would practically jump across if needed
yes, that's what the wiki definition for stream states. The definition for
river on the other hand requires the feature
2013/10/18 Christoph Hormann
> If you think this information is completely unreliable you can of course
> ignore it all together. But keep in mind the river/stream distinction
> is not an importance rating, therefore it is fully possible for a river
> to run into a stream.
>
this discussion be
> Am 02/nov/2013 um 17:52 schrieb Pieren :
>
> Cutting lines have their own tag:
> http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcutline
Yes, but that doesn't mean you can't split the forest there. My suggestion is
to use the smallest polygons that make sense according to the mapper, and
Actually it didn't look to me as if you had substantial changes proposed. A
"should" has IMHO the same implications in this context than a "must", and
whether this is called "policy" or "guidelines" doesn't seem to change
anything either, that's why I didn't reply on your first mail.
cheers,
Marti
2013/11/6 Carol Kraemer
> Good morning Martin,
>
> "Guidelines" often read as suggested reading while "Policy" carries more
> weight and defined consequences for not following it.
>
> -
>
yes, in general it is clear, but there is a quite verbal text how to read
these guidelines:
These guidelin
2013/11/6 Christoph Hormann
> Also keep in mind that it might seem clear to long
> term mappers what things like 'revert plan' and 'changeset size policy'
> are but need to be explained in a practically useful set of
> instructions (at best with links to examples of good practice).
>
IMHO impor
2013/11/22 Paul Norman
> There's no list of tags on that page, could you just provide a list of
> tags in an email to the list?
>
there's a link to this file:
https://wiki.openstreetmap.org/wiki/Veneto/File_delle_Regole_SHP-to-OSM
some remarks:
- it should be amenity=post_office (instead of p
2013/11/21 sabas88
> Data is downloadable here
> http://www.sardegnageoportale.it/catalogodati/download
>
> and we are organizing imports on chat, we have started a wiki page here
> http://wiki.openstreetmap.org/wiki/Sardegna/Import
>
> Currently the data involved will be at least buildings, road
2013/11/24 Martin Raifer
> * If you had an address dataset that positions the addresses at or near to
> the respective building entrances: Wouldn't it make sense to not conflate
> the address data with building outlines? (Because by conflating the
> usefulness of the data would actually be reduce
> Am 28/nov/2013 um 04:09 schrieb "Andreas Uller" :
>
> Any feedback is welcome.
>
this is not directly related to your import, but a disused highway=bus_stop may
still be interesting in OSM, if there are physical remains (e.g. shelter, bench
and for orientation). This depends on the area
2013/12/3 Andreas Uller
> The operator is not included in the data provided for the import, and
> often there will be several bus line operators stopping at the same bus
> stop. However, the operator tag is included in the bus route relations, so
> it can be deducted from that, if someone wanted
2013/12/4 Greg Troxel
> Thanks for the explanation. Given that, village as admin_level=10 (or 9
> if you want) sounds like exactly the right thing for me.
> Perhaps rendering will need to catch up.
>
> This was interesting to read. Villages as a political entity in Vermont
> seem far more firml
2013/12/10 Christian Wegerhoff
Great to see the WSV data liberated.
This applies in particular to harbor=yes/seamark:type=harbor and
> historic=wreck/seamark: type=wreck.
As a sidenote, there is a typo, it should be (and according to taginfo is)
"harbour" because we use the British English sp
2013/12/10 Martin Koppenhoefer
> E.g. seamark:type=harbour is fine for a seamark indicating a harbour, but
> it isn't (IMHO) a nice tag for the harbour itself.
it seems though, that what is currently done is exactly this: add
seamark:type=harbour to the whole area of the har
> Am 11/dic/2013 um 17:04 schrieb Christian Wegerhoff :
>
> There will be no such tags in the IENC data, so this is off topic here.
>
>
I agree, there is a followup thread in tagging about the seamark prefix for
stuff that isn't a seamark.
https://lists.openstreetmap.org/pipermail/tagging/
2013/12/14 Jason Remillard
> From the file, here are the actual tags+values.
>
> building:fireproof=no
> building:fireproof=yes
>
> - Could you make a wiki page for this tag. It is used 90,000+ times.
> It seems to be just from already started import?
>
+1, there should probably be a definition
2013/12/19 Satoshi IIDA
> OK, I'll change "source=" to changeset comment.
> (import files and wiki page are modified already)
>
or maybe better to a changeset tag "source" instead of the "comment".
cheers,
Martin
___
Imports mailing list
Imports@opens
2014/1/8 Severin MENARD
> Paul,
>
> I took you only 24 hours in December to stop this import. I would
> appreciate the same speed to help us solving the issue(s) you identified
> for this import that has humanitarian benefits.
>
if the import is not done nicely and the data or tagging has issue
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 this tag when editing one of the objects? How much
would you have to modify them in order to remove the tag? O
> 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,
Martin
___
Imports mailing list
Imports@openstreetmap
> Am 25/gen/2014 um 11:16 schrieb Michal Palenik :
>
> just of curiosity: is there an easy way (josm plugin/...) to view
> history of a node/way/relation as given by changeset source tags?
ctrl+h
then click on changeset link
___
Imports mailing list
there is also the tag "network" that might be interesting to look at
in this context:
http://wiki.openstreetmap.org/wiki/Key:network
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
cheers,
Martin
___
Imports mailing list
Imports@op
2011/8/26 Bryce Nesbitt :
>> My only technical comment regarding your script is that we usually put the
>> source tag(s) on the changeset, not the individual node, nowadays.
> But I'd like to keep source tags on the node, so hand mappers can understand
> that the data is mastered elsewhere.
if t
> Am 05/feb/2014 um 00:11 schrieb Andrzej Kępys :
>
> Kind of the law requires but only few respects it, so
> collecting this data in the field is almost impossible.
you could ring at their door and ask them ;-)
Anyway, if you can't find the number in the real world it is also of much fewer
u
> Am 06/feb/2014 um 22:27 schrieb Johan C :
>
> associatedStreet relations on address nodes) in your opinion create a bad
> experience for a new mapper?
if stuff looks too complex it will draw away some people with initial interest
in osm, associated street relations are one of these factors
2014-02-07 12:16 GMT+01:00 Christian Quest :
> If an import results has the same data structure and quality as any manual
> contribution, what's the problem ?
>
I hope this should have been quality as many _good_ manual contributions,
because we have a lot of not so optimal manual contributions
2014-02-11 11:28 GMT+01:00 Pieren :
> I
> don't care much about the different ones but I hate small areas mixing
> them.
>
I'd prefer the most simple approach (nodes, no relation), as it makes
maintenance easier for unexperienced mappers and for those using less
capable editors.
cheers,
Martin
_
2014-02-20 3:26 GMT+01:00 Zbigniew Czernik :
> > - 98% of the addresses in this file could have the building=yes tag
> applied.
>
> I don't think so. How I can determine which address should have the
> building tag? Should I compare every address with imagery?
Yes you could do this, but it woul
2014-03-11 12:01 GMT+01:00 Serge Wroclawski :
> The current meaning doesn't fit the meaning of the English word at
> all, which is part of our tagging "philosophy" (that tags should make
> sense in English).
>
Really? Is this stated anywhere? How does it relate to amenity=prison? Or
to highway=s
2014-03-12 20:06 GMT+01:00 Petr Vejsada :
> It exist in 8 cities only. Total count of meststa cast is 143. Mestska cast
> has an administrative power. It has absolutely no relationship to
> periphery.
> It can be in periphery as well as in city town. There are no boundaries of
> mestska cast in OS
2014-03-12 21:01 GMT+01:00 Petr Vejsada :
> Petr Vejsada
> Boleslavska 20/1989
> 130 00 Praha 3
> Czech republic
>
> (it is not secret, it's in public registry like whois etc.) ;-)
>
> It can be written also as:
>
> Petr Vejsada
> Boleslavska 20/1989
> 130 00 Praha 3 - Vinohrady
> Czech republic
Looking at actual usage numbers [1] for the tag "source:maxspeed" I noticed
that a lot of uses that deviate from the key docu [2] in the wiki, actually
came in by imports, namely
- FDOT␣"Maximum␣Speed␣Limits"␣GIS␣data,␣updated␣August␣27,␣2011:␣
http://www.dot.state.fl.us/planning/statistics/gis/r
> Am 20/mar/2014 um 16:29 schrieb Christian Quest :
>
> In some cases yes (maybe not that one), when the speedlimit is directly
> painted on the road...
yes, the proposed value is "markings" (currently used only 8 times)
cheers,
Martin
___
Imports ma
2014-03-20 17:25 GMT+01:00 SomeoneElse :
> On 20/03/2014 15:15, Martin Koppenhoefer wrote:
>
>
> also this one seems strange:
> BING␣+␣wiedza␣własna<http://taginfo.openstreetmap.org/tags/source%3Amaxspeed=BING%20%2B%20wiedza%20w%C5%82asna>
> (can you get speed limits
> Am 22/mar/2014 um 11:48 schrieb Christoph Hormann :
>
> - in central Europe bare rock is rarely continuous over areas large
> enough to be sensibly mapped on the scale of CLC.
scale is a good point with regard to CLC in general: insufficient in CLC
compared to osm scale. that's why CLC ha
> Am 22/mar/2014 um 08:32 schrieb "Paul Norman" :
>
> 2. Are there other CLC classifications which are just as bad?
IMHO CLC generally not suited for OSM due to the scale.
cheers,
Martin
___
Imports mailing list
Imports@openstreetmap.org
https://li
> Am 22/mar/2014 um 21:59 schrieb Pieren :
>
> Because if you remove CLC meadow, you
> should remove all CLC landuses. And you should not stop in France but
> go ahead for all European countries where CLC was imported because it
> was the same source/process,
+1
cheers,
Martin
__
2014-03-20 17:37 GMT+01:00 Martin Koppenhoefer :
> 2014-03-20 17:25 GMT+01:00 SomeoneElse :
>
> On 20/03/2014 15:15, Martin Koppenhoefer wrote:
>>
>>
>> also this one seems strange:
>> BING␣+␣wiedza␣własna<http://taginfo.openstreetmap.org/tags/source%3Amaxspe
Am 23/mar/2014 um 13:10 schrieb "Paul Norman" :
>>> :
>>>
>>> Because if you remove CLC meadow, you
>>> should remove all CLC landuses. And you should not stop in France but
>>> go ahead for all European countries where CLC was imported because it
>>> was the same source/process,
>>
>> +1
>
>
2014-03-24 10:56 GMT+01:00 Pieren :
> Altrough the CLC program is european,
> it's done by many different operators in a long run. The quality
> varies from region to region.
>
yes, but generally the quality is good :)
The problem is the scale, CORINE is in scale 1:100.000, while our tiles go
to
2014-03-23 21:48 GMT+01:00 Richard Welty :
> i think it's worth pointing out that NE2's use of source:maxspeed
> was not controversial and had nothing to do with his departure.
>
+1 that it wasn't the reason that he left and it wasn't discussed with him
at the time, but yet it was controversial
2014-03-26 6:43 GMT+01:00 Dalibor Jelínek :
> We will even erase these tags from existing address nodes during the
> import as we want to have all Czech addresses in the same format.
you should not do this. Please do not automatically delete tags that were
entered manually.
cheers,
Martin
___
2014-03-26 15:40 GMT+01:00 Pieren :
> On Wed, Mar 26, 2014 at 3:20 PM, Martin Koppenhoefer
> > you should not do this. Please do not automatically delete tags that were
> > entered manually.
>
> I think there is a large consensus that some tags like "addr:country"
2014-03-27 5:18 GMT+01:00 Dalibor Jelínek :
> Well, I agree with Pieren.
>
> Either the tags are necessary or they are not, it cannot be both.
>
these tags are often not necessary, but sometimes they are indeed helpful.
E.g. if close to a border having the addr:country tag is useful for
practic
2014-03-29 19:18 GMT+01:00 Rob Nickerson :
> I would strongly recommend that you use the maxspeed:type tag [2] as it
> less likely to suffer from the same problem you have identified. We use
> this tag in the UK and as such the following tag combination is valid:
Somehow I feel tempted to do so
2014-04-03 14:45 GMT+02:00 Richard Weait :
>
> Introduction:
> I have a source for posted speed limit data. This thread begins the
> discussion of the data, the origin and quality of the data, and the
> suitability of the data to OpenStreetMap.
>
does it contain the positions of speed limit sig
2014-05-04 20:59 GMT+02:00 Elliott Plack :
> In my experience, place=hamlet,village,town,city are *better placed as
> nodes* at the boundary centroid, rather than with ways representing the
> boundary. Mapnik and Mapbox use the nodes rather than the boundary lines to
> render. I am pretty familiar
2014-05-05 19:17 GMT+02:00 Elliott Plack :
> Martin, thanks for pointing that out. I should clarify. I'm not against
> this import so long as the community thinks boundaries are good for OSM. As
> for the place=* tags, if there isn't a conflict in placing them both on the
> boundary and a node, th
> Am 06/mag/2014 um 09:01 schrieb Andrew Guertin :
>
> ...and that seems more appropriate for the official_name= tag.
+1
cheers,
Martin
___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports
2014-05-12 2:44 GMT+02:00 Satoshi IIDA :
> There are some arguments to change "Prefecture" system to "State" system
> in Japan politics.
> (yes, it would take long years indeed...)
>
> If this change would be applied even as partially, we could not keep a way
> to represent the new systems.
> So I
2014-05-12 13:39 GMT+02:00 Satoshi IIDA :
> So I do not have intention to add "place" tag to Way or Relation objects.
> I think "place" tag is to be used to Node (as relation's "admin_centre"
> role member).
I didn't mean to argue against tagging settlements, or parts of them, as
areas, my poin
2014-05-28 23:48 GMT+02:00 malenki :
> Since I got some strange questions this is what I want to do in a
> nutshell:
> For all objects with WorstFixer has touched with water=lake;pond on
> them:
>
> drop all tags except
> natural=water
> source=NHD
> intermittent=yes
>
do you have a complete lis
2014-05-29 11:42 GMT+02:00 Serge Wroclawski :
>
> > gnis:feature_id=* 26
> > gnis:id=* 6577
>
> The US community has discussed these tags and wants them to stay. Do
> not remove them. I'd call any removal of those vandalism.
>
Do you have guidelines or suggestions how to hand
2014-06-06 3:02 GMT+02:00 Alex Barth :
> - Preserve existing buildings where they had higher quality than import
> buildings
I think it is preferable to reuse all existing geometry (if possible), e.g.
you can use replace geometry from the utilsplugin2 to preserve history and
tags:
http://wiki.
> Am 21/giu/2014 um 23:03 schrieb Paul Norman :
>
> As a reminder, CC BY 3.0 and earlier are incompatible for reasons related to
> the attribution requirements.
can you expand on this? I remember there are already heaps of data with these
licenses (cc-by 3.0 and older) in OSM.
cheers,
Marti
> Am 17/lug/2014 um 20:17 schrieb Vitor George :
>
> It seems that the proper tagging would be waterway=ditch+tunnel=yes as they
> are mostly underground man-made channels.
using ditch on an underground feature seems a bit odd to me. I'd use
waterway=stream (presuming these are not man made
1 - 100 of 283 matches
Mail list logo
