sent from a phone
> On 12. Sep 2019, at 13:52, Frederik Ramm wrote:
>
> Do we even have a remote hope of achieving a
> level of completeness and timeliness that makes this usable?
if your apprehension comes true and we became the default go-to business
directory, then definitely yes (but we
I have reworked the page as per your instructions, please let me know if it
still needs more clarification.
https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dopen_defecation
Cheers
Bob
> On 13 Sep 2019, at 03:13, Joseph Eisenberg wrote:
>
> Thanks for working on this, Bob,
>
>
marc marc wrote:
"well in this case, this shop isn't a bulk_purchase=yes shop
bulk_purchase=* in osm mean that you can BUY item in bulk
not that the shop has a stock of product that he packs for you on site.
bulk_purchase informs how the customer can have the product and not in
what form the stoc
On Fri, 13 Sep 2019 at 11:04, Antoine Jaury via Tagging <
tagging@openstreetmap.org> wrote:
> marc marc wrote:
>
> "well in this case, this shop isn't a bulk_purchase=yes shop
> bulk_purchase=* in osm mean that you can BUY item in bulk
> not that the shop has a stock of product that he packs for y
On 11/09/2019 14:50, Paul Allen wrote:
I said that if it was a church and looks like a church then tag the building as
a church even if it now functions as something else.
Buildings don't have a 'type'. There's no 'class', no standard
architectural style or size. A quick image search proves
On Fri, Sep 13, 2019 at 9:20 AM Dave F via Tagging
wrote:
> On 11/09/2019 14:50, Paul Allen wrote:
> >
> > I said that if it was a church and looks like a church then tag the
> > building as a church even if it now functions as something else.
>
> Buildings don't have a 'type'. There's no 'class'
I certainly recall reading about this in the wiki, but I agree that in
common use, the building=* tag appears to be used mostly for the
current function, rather than specifying a certain form.
The most common values of building= are:
0) yes (non-specific)
1) =house - both a structural form and a
* Joseph Eisenberg [190913 16:45]:
> I certainly recall reading about this in the wiki, but I agree that in
> common use, the building=* tag appears to be used mostly for the
> current function, rather than specifying a certain form.
That would be kind of redundant, wouldn't it? We already use ot
On Thu, 12 Sep 2019 at 09:45, Janko Mihelić wrote:
One problem with the current system is that if you click one of those
> dwarfs in OSM, and see it's linked to an object in wikidata, you have no
> way of seeing if that is the whole wikidata object, or just a part of that
> object, unless you dow
pet, 13. ruj 2019. u 17:31 Paul Allen napisao je:
> On Thu, 12 Sep 2019 at 09:45, Janko Mihelić wrote:
>
> The correct way to group them is with a relation. If we don't have a
> suitable type of relation then propose one.
>
My idea was to expand the general "part:wikidata=*" to more specific
On Fri, 13 Sep 2019 at 17:31, Janko Mihelić wrote:
My idea was to expand the general "part:wikidata=*" to more specific tags.
> For example, give all peaks and ridges of a mountain the
> mountain:wikidata=* tag, instead of part:wikidata=*. Part is just the
> first, nondescript step. If we decide
On Fri, 13 Sep 2019 18:29:04 +0200
Janko Mihelić wrote:
> pet, 13. ruj 2019. u 17:31 Paul Allen napisao je:
>
> > On Thu, 12 Sep 2019 at 09:45, Janko Mihelić
> > wrote:
> >
> > The correct way to group them is with a relation. If we don't have
> > a suitable type of relation then propose one
On Wed, 11 Sep 2019 at 13:41, Janko Mihelić wrote:
> sri, 11. ruj 2019. u 14:34 Joseph Eisenberg
> napisao je:
>>
>> Doesn't this mean that it would be better to create separate Wikidata
>> items for each separate OSM feature, rather than creating a new OSM
>> tag?
> You have examples like tag
On Wed, 11 Sep 2019 at 13:58, Paul Allen wrote:
>
> On Wed, 11 Sep 2019 at 13:35, Martin Koppenhoefer
> wrote:
>> looking at the example, it seems here is such an issue with
> the "canonization status"=catholic saint. Why do the individual
> saints not have the property, but the group has it?
On Wed, 11 Sep 2019 at 17:02, Mateusz Konieczny wrote:
> Entries about shop brands (used in name suggestion index) got deleted.
That was over-zealous anti-spam action. Many such deletions were
challenged and reverted; any others should have been.
In such cases, including third-party identifiers
On Wed, 11 Sep 2019 at 19:48, Paul Allen wrote:
>
> On Wed, 11 Sep 2019 at 19:43, Mateusz Konieczny
> wrote:
>> It gets tricky where wikidata has a
>> single object for things like
>> lake and surrounding wetlands
>
>
> Then the wikidata item is for the wetlands, which happen to have a lake
>
On Wed, 11 Sep 2019 at 22:24, Janko Mihelić wrote:
> Art or memorial installations like Stolperstein[1], which
> are distributed, but have one wikidata item.
We already cater for this, using sub-tags; say:
project:wikidata=Q314003
or:
memorial:wikidata=Q26703203
(see https://www.w
On Fri, 13 Sep 2019 at 19:47, Andy Mabbett
wrote:
> On Wed, 11 Sep 2019 at 13:58, Paul Allen wrote:
>
> > if there is a property shared by all members of a group then it MUST be
> marked on
> > the group ALONE and not also on individual members.
>
> This is not the rule on Wikidata.
>
But I was
On Thu, 12 Sep 2019 at 09:43, Janko Mihelić wrote:
> Currently, the second most numerous wikidata tag in OSM
> is https://www.wikidata.org/wiki/Q2961670, an item that
> describes all the roman roads in historic Gaul in France. All
> those ways, close to 500 of them, have wikidata=Q296167.
Can we
On 13/09/2019 16:14, Wolfgang Zenker wrote:
That would be kind of redundant, wouldn't it? We already use other tags
for the current function of a building,
I'm repeating much of my of my previous comment, but no, the schema
which hijacked building=* to represent the original historical function
13 Sep 2019, 20:28 by a...@pigsonthewing.org.uk:
> On Wed, 11 Sep 2019 at 13:41, Janko Mihelić wrote:
>
>> sri, 11. ruj 2019. u 14:34 Joseph Eisenberg
>> napisao je:
>>
>>>
>>> Doesn't this mean that it would be better to create separate Wikidata
>>> items for each separate OSM feature, rath
* Dave F via Tagging [190913 21:37]:
> On 13/09/2019 16:14, Wolfgang Zenker wrote:
>> That would be kind of redundant, wouldn't it? We already use other tags
>> for the current function of a building,
> I'm repeating much of my of my previous comment, but no, the schema
> which hijacked building
open_defecation=yes seems a better tag for all situations where it is a
significant phenomenon, while landuse=open_defecation would be ok for areas
that are either designated for open defecation or are mainly used for it.
Cheers Martin
___
Tagging ma
13 Sep 2019, 21:37 by tagging@openstreetmap.org:
> On 13/09/2019 16:14, Wolfgang Zenker wrote:
>
>
>>
>> That would be kind of redundant, wouldn't it? We already use other tagsfor
>> the current function of a building,
>>
> I'm repeating much of my of my previous comment, but no, the schema
On 13/09/19 12:13, Joseph Eisenberg wrote:
Thanks for working on this, Bob,
Check out the page "Proposal_process" and in particular
Proposal_process#Creating_a_proposal_page to help improve the
formatting and make sure you've included important information.
Please clarify exactly what should be
On 12/09/19 21:52, Frederik Ramm wrote:
Hi,
Do we really want to go
into that effort of trying to actively represent what products are sold
and under what conditions? Do we even have a remote hope of achieving a
level of completeness and timeliness that makes this usable? Where does
it stop?
I agree, we shouldn’t create relations that combine 7 separate artworks
into one, or all the ways with the same street name, or all the peaks and
ridges in a mountain_range, just so that a wikidata= tag can be added to
the relation.
Relations are harder to maintain, and in the cases above are not
There's a new-ish page about the prefix "not:"
https://wiki.openstreetmap.org/wiki/Key:not:
It's been used with "not:name" to show that a street isn't named
something else (e.g. for streets that had the wrong name on official
OS maps in Britain): https://wiki.openstreetmap.org/wiki/Key:not:name
I've added "amenity=music_school" back to the Map Features list, since
it looks like there is consensus that this is different than
amenity=college and there is not other tag for this feature at this
time. And I edited it's wiki page to mention isced:level as a possible
combination.
- Joseph
On 9
Hello Joseph,
I have to say that I'm not a fan of the tag, IMHO negation is something
that will make harder to do searches...
If the burger king is not the food chain keep the brand empty and write a
note or do a Wikipedia page about it, probably an historical activity
deserve it.
About the no na
"noname=yes" is used when a feature like a road doesn't have a name.
The tag :not:name=XXX" is used when mappers might think that the name
is actually "XXX" but it's not. Usually the "name=" field is already
set with the correct name: 96% of objects with "not:name" have a
"name=*" - see https://ta
31 matches
Mail list logo
