Re: [Tagging] New tag proposal: 'addr=milestone'

Am Mi., 20. Nov. 2019 um 06:56 Uhr schrieb Jorge Aguirre < jorge.agui...@kaart.com>: > I had been out for the last few weeks and had left this proposal in > standby. I am back now and have revised and updated the original proposal > and included some images as examples, so hopefully it is all mor

Re: [Tagging] New tag proposal: 'addr=milestone'

two (Mateusz Konieczny) > 4. Re: Divided highways, and not so divided highways, one way or > two (Dave Swarthout) > > > -- > > Message: 1 > Date: Thu, 10 Oct 2019 00:26:07 -0300 > From: Agusti

Re: [Tagging] New tag proposal: 'add=milestone'

> > this implies road markers must be present, right? Isn’t this mainly about the > distance from some zero point, even in the absence of road distance markers? > > No, many times there are no marks, for me it does not have to be implicit I would not invent myself these numbers, I would copy them

Re: [Tagging] New tag proposal: 'add=milestone'

Hi, I just want to bring to your attention the work currently done to propose marker=* key with existing value marker=stone. https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal#Tagging This is mainly intended for utility networks but may be useful for highways milestone

Re: [Tagging] New tag proposal: 'add=milestone'

Am Mi., 9. Okt. 2019 um 15:11 Uhr schrieb Paul Allen : > ...some mad king throwing darts at a map: if it looks like a house number, > is treated like a house > number, and appears on the house/gate/whatever as a house number, then > it's a house number. > House numbers don't have to be sequential

Re: [Tagging] New tag proposal: 'add=milestone'

On Wed, 9 Oct 2019 at 09:39, Martin Koppenhoefer wrote: > > Funfact, in Rome there is one road, "Via Trionfale", > https://en.wikipedia.org/wiki/Via_Trionfale which has housenumbers > (contrary to the rest of the city) that indicate the distance from the > capitol hill measured at the axxis of th

Re: [Tagging] New tag proposal: 'add=milestone'

Am Mi., 9. Okt. 2019 um 09:00 Uhr schrieb Colin Smale : > I would just like to make a point about mileages/kilometrages. Physically > marked positions (e.g. a milestone or a sign with an address) can not be > replaced by, or derived from, the actual distance along the road. > > These distances are

Re: [Tagging] New tag proposal: 'add=milestone'

I would just like to make a point about mileages/kilometrages. Physically marked positions (e.g. a milestone or a sign with an address) can not be replaced by, or derived from, the actual distance along the road. These distances are not constant. Roads get diverted, split, recombined etc which ca

Re: [Tagging] New tag proposal: 'add=milestone'

sent from a phone > On 9. Oct 2019, at 03:24, Jorge Aguirre wrote: > > After reading all the responses and comments made regarding this issue I > would like to modify the originally proposed tag name ('addr=milestone’) to a > new proposal to name it: ‘addr=road_marker’ - which works for bot

Re: [Tagging] New tag proposal: 'add=milestone'

------------ > > Message: 1 > Date: Wed, 2 Oct 2019 17:54:35 -0300 > From: Agustin Rissoli > To: tagging@openstreetmap.org > Subject: Re: [Tagging] New tag proposal: 'addr=milestone' > Message-ID: > > C

Re: [Tagging] New tag proposal: 'addr=milestone'

Am Mi., 2. Okt. 2019 um 22:55 Uhr schrieb Agustin Rissoli < aguztin...@gmail.com>: > I think we can add a clarification, which says that these directions are > not exact, but usually based on the approximate position with respect to a > milestone on the road. > Actually I have 2 different cases

Re: [Tagging] New tag proposal: 'addr=milestone'

Re: “On standard [OpenStreetMap-]carto (and probably most others) highway=milestone doesn't render.” There is an open issue and some rendering ideas from a year back: https://github.com/gravitystorm/openstreetmap-carto/issues/3605 If anyone wants to help get historic=milestone rendered, they can

Re: [Tagging] New tag proposal: 'addr=milestone'

tools" Subject: Re: [Tagging] New tag proposal: 'addr=milestone' Message-ID: Content-Type: text/plain; charset="utf-8" On Wed, 2 Oct 2019 at 18:59, Agustin Rissoli wrote: > > > > Perfect! That is exactly what happens in real life when someone is > seek

Re: [Tagging] New tag proposal: 'addr=milestone'

On Wed, 2 Oct 2019 at 18:59, Agustin Rissoli wrote: > > > > Perfect! That is exactly what happens in real life when someone is > seeking an address based on location markers once the precision of the > distance used in addresses is low. > > This description should be in the eventual wiki > You t

[Tagging] New tag proposal: 'addr=milestone'

Jorge, I think we should change the name of the tag to addr:road_marker or another, as many are not interested in milestone not being the correct name, nor should they care that it does not match highway=milestone, it is a lesser evil. > Think of the ‘milestone’ as a point of reference. The ‘miles

Re: [Tagging] New tag proposal: 'addr=milestone'

On Wed, 2 Oct 2019 at 14:57, Martin Koppenhoefer wrote: this is also a milestone in OSM: historic=milestone > https://wiki.openstreetmap.org/wiki/Tag:historic%3Dmilestone > There aren't that many milestones (made of stone, marked in miles) around here but all of those I'm aware of are historic a

Re: [Tagging] New tag proposal: 'addr=milestone'

Am Mi., 2. Okt. 2019 um 13:33 Uhr schrieb Paul Allen : > NO. NO, NO, NO, NO, NO. That's how we end up with bad tags. Like > highway=milestone. > Outside of OSM, a milestone is a stone with a distance in miles marked > upon it. Outside > of OSM, this is a milestone: > https://en.wikipedia.org/w

Re: [Tagging] New tag proposal: 'addr=milestone'

On Wed, 2 Oct 2019 at 13:26, santamariense wrote: > > > that you should not use the term "milestone" but something like > > addr:distance or > > addr:road_marker or whatever, because there are no milestones > > addr:road_marker seems to be appropriated Or something with similar meaning. Place

Re: [Tagging] New tag proposal: 'addr=milestone'

> which coincidentally can match (or not match) the distance Well noted. The reference to a location marker used in an address rarely gives the exact distance. It is an approximated value with low precision, unlike the tag distance=* that is used with highway=milestone that is supposed to mark the

Re: [Tagging] New tag proposal: 'addr=milestone'

On Wed, 2 Oct 2019 at 03:40, Jorge Aguirre wrote: > > In all fairness, I think it should not be as difficult to find a good way > to facilitate entering a complementary address tag, one that is very much > needed in our part of the world - one which applies to and needed in most > of the world ac

Re: [Tagging] New tag proposal: 'addr=milestone'

Greetings my fellow OSM colleagues. In all fairness, I think it should not be as difficult to find a good way to facilitate entering a complementary address tag, one that is very much needed in our part of the world - one which applies to and needed in most of the world actually. This has be

Re: [Tagging] New tag proposal: 'addr=milestone'

Yes, we call them "mile markers" in my part of Oregon/Northern California too, like "the wildfire started on the north side of Highway 96 at mile marker 23" - but houses and other structures have addresses with house numbers. On 10/2/19, Dave Swarthout wrote: > The "milestone" value is a misnomer

Re: [Tagging] New tag proposal: 'addr=milestone'

The "milestone" value is a misnomer in most modern situations. Here in Thailand, many roads have actual mile markers, er kilometer markers, but they are not made of stone. They are painted concrete. In the U.S. there are very few of these if any. When I'm tagging mile markers in the U.S., I include

Re: [Tagging] New tag proposal: 'addr=milestone'

> I think we're close to hitting the record for how misleading a tag name can > be. Maybe. > This is a proposal for a tag addr:milestone to allow us to specify a > distance in kilometres > (not miles), of a house (not a milestone) and the nearest milestone isn't a > stone but a sign. It could be

Re: [Tagging] New tag proposal: 'addr=milestone'

Il giorno mar, 01/10/2019 alle 23.09 +0200, Tobias Zwick ha scritto: > Milestones are not necessarily located at the true distance of A to > B. Not sure why this is the case, but I know that this is true for at > least Thailand. > On 01/10/2019 21:10, Paul Allen wrote: > > On Tue, 1 Oct 2019 at 19

Re: [Tagging] New tag proposal: 'addr=milestone'

On Tue, 1 Oct 2019 at 18:11, Mark Wagner wrote: > On Tue, 01 Oct 2019 09:01:06 +0200 > Colin Smale wrote: > Instead, linear position gets turned into a house number. For example, a > building > eight and a half miles from the start of Long Road might be "850 > Long Road". > That's why I asked

Re: [Tagging] New tag proposal: 'addr=milestone'

Milestones are not necessarily located at the true distance of A to B. Not sure why this is the case, but I know that this is true for at least Thailand. On 01/10/2019 21:10, Paul Allen wrote: > On Tue, 1 Oct 2019 at 19:40, Jorge Aguirre > wrote: > > The add

Re: [Tagging] New tag proposal: 'addr=milestone'

On Tue, 1 Oct 2019 at 19:40, Jorge Aguirre wrote: The addresses that utilize ‘Km’ as part of the actual address are always > related to a specific 'highway:milestone’ on that particular highway. For > instance, the address for the Hilton Guatemala Vista Real Hotel in > Guatemala - as it appears o

Re: [Tagging] New tag proposal: 'addr=milestone'

ned:key=* lifecycle prefixes? (Kevin Kenny) > 4. Re: Strange tags (Paul Allen) > 5. Re: Strange tags (Martin Koppenhoefer) > > > -- > > Message: 1 > Date: Tue, 1 Oct 2019 14:06:48 +0100 > From:

Re: [Tagging] New tag proposal: 'addr=milestone'

What I'm unclear on is if these addresses refer to an actual road marker, or an actual distance based upon interpolation between actual road markers. If you have a road marker at 8km and another road marker at 9km, would a house between the two have addr:milestone 8, 9 or 8.5? If the address is o

Re: [Tagging] New tag proposal: 'addr=milestone'

On Tue, 1 Oct 2019 at 13:34, santamariense wrote: > > I am not sure about to keep "Km". It might be understandable by the > key 'addr:milestone' itself. It might. OSM uses highway=milestone to mean a road marker in general, rather than a traditional milestone (which was a stone with distances

Re: [Tagging] New tag proposal: 'addr=milestone'

This tag only comes to give a standard to something that already is being mapped off the cuff. When you search by "KM" in https://taginfo.openstreetmap.org/keys/addr:housenumber#values you will find 2758 addr:housenumber that contains "KM" as part of their values. Such information can be even found

Re: [Tagging] New tag proposal: 'addr=milestone'

On Tue, 01 Oct 2019 09:01:06 +0200 Colin Smale wrote: > On 2019-10-01 08:18, Florian Lohoff wrote: > > > Hi Jorge, > > > > On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote: > > > >> Throughouthe entire Latin American region and some other parts of > >> the world, it is quite co

Re: [Tagging] New tag proposal: 'addr=milestone'

> I may be mistaken but I seem to remember mile markers being used in rural areas of the USA to indicate linear position along a main road. You are not mistaken. Many hotels and parks in the rural areas of Alaska mark their location that way. On Tue, Oct 1, 2019 at 2:06 PM Colin Smale wrote: >

Re: [Tagging] New tag proposal: 'addr=milestone'

sent from a phone > On 1. Oct 2019, at 08:18, Florian Lohoff wrote: > > We have such addresses in Germany too. In Italy you can find them as well, they are not uncommon for properties along through roads outside of settlements and for highway rest areas. Currently I’m either using addr:full

Re: [Tagging] New tag proposal: 'addr=milestone'

On 2019-10-01 08:18, Florian Lohoff wrote: > Hi Jorge, > > On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote: > >> Throughouthe entire Latin American region and some other parts of >> the world, it is quite common to find the kilometer (Km.) information, >> as may be found on the "h

Re: [Tagging] New tag proposal: 'addr=milestone'

Hi Jorge, On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote: > Throughout the entire Latin American region and some other parts of > the world, it is quite common to find the kilometer (Km.) information, > as may be found on the “highway:milestone”, as part of the actual > addresses. M

Re: [Tagging] New tag proposal: 'addr=milestone'

Could you please give us an example photo, Jorge? Thanks Graeme On Tue, 1 Oct 2019 at 12:18, Jorge Aguirre wrote: > Throughout the entire Latin American region and some other parts of the > world, it is quite common to find the kilometer (Km.) information, as may > be found on the “highway:mi

[Tagging] New tag proposal: 'addr=milestone'

Throughout the entire Latin American region and some other parts of the world, it is quite common to find the kilometer (Km.) information, as may be found on the “highway:milestone”, as part of the actual addresses. Mostly used in suburban and rural areas, which may usually not even have any vis

Re: [Tagging] New tag office=consulting was added to Map Features

Le 28.08.19 à 11:19, Joseph Eisenberg a écrit : > New description is 'An office for a consulting firm, > providing expert professional advice to other companies." at least a tag to specify the activity should be provided, because with the current description, an accounting, IT security, agricult

[Tagging] New tag office=consulting was added to Map Features

Another user just created the page https://wiki.openstreetmap.org/wiki/Tag:office%3Dconsulting and added the tag to Map_Features It's been used since 2012, with over 100 uses since 2013 and now is up over 600, but it didn't have a page before. New description is 'An office for a consulting firm,

Re: [Tagging] New Tag "Departures" voting results.

maybe we can use some keys like eta_link:shortnameofbuscompanyA=* and eta_link:shortnameofbuscompanyB=* to show different operators information 在 2019年3月13日週三 15:01，Graeme Fitzpatrick 寫道： > > > On Wed, 13 Mar 2019 at 14:30, Phake Nick wrote: > >> but in term of GTFS I don't think anyone in the

Re: [Tagging] New Tag "Departures" voting results.

On Wed, 13 Mar 2019 at 14:30, Phake Nick wrote: > but in term of GTFS I don't think anyone in the world supply data > individually for each stops. > Of course! It would be nice (but probably impossible) to have a single worldwide answer but I don't think that will be possible in the foreseeable

Re: [Tagging] New Tag "Departures" voting results.

There are processed data for each stop, but in term of GTFS I don't think anyone in the world supply data individually for each stops. My understanding is that each GTFS file usually cover a line or a network. 在 2019年3月13日週三 10:32，Graeme Fitzpatrick 寫道： > > > On Wed, 13 Mar 2019 at 11:18, Andrew

Re: [Tagging] New Tag "Departures" voting results.

For the coordinated schedule, as an example there is a route that departure at the following time: 08:00, 08:00, 08:03, 08:06, 08:09, 08:12, 08:15, 08:18, 08:22, 08:25, 08:29, 08:33, 08:38, 08:38, 08:38, 08:41, 08:44, 08:47, 08:51, 08:54, 08:57, 09:01, 09:05, 09:09, 09:13, and of these departures,

Re: [Tagging] New Tag "Departures" voting results.

On Wed, 13 Mar 2019 at 11:18, Andrew Davidson wrote: > However, you may want to include the feed_id every > time to make it easier to search for stops. Also do we want to repeat > the same information at every stop or should we store it in a single > relation? > Unless I've misunderstood the que

Re: [Tagging] New Tag "Departures" voting results.

On 2/3/19 10:02 am, Leif Rasmussen wrote: > It seems like the best way forward now is for a proposal allowing OpenStreetMap data to be tightly integrated with outside sources (such as GTFS) to be created by someone.  This would avoid the issues of maintainability in OpenStreetMap. I'm not int

Re: [Tagging] New Tag "Departures" voting results.

sent from a phone > On 7. Mar 2019, at 15:02, Phake Nick wrote: > > The route us currently operated by two different operators on coordinated > timetable and each operator have their own ETA system. While they do not > provide a GTFS feed for now, it can be expected that each of them will >

Re: [Tagging] New Tag "Departures" voting results.

sent from a phone > On 7. Mar 2019, at 13:06, Paul Allen wrote: > > It's just that at one time the bus will have the > livery of "Foo Brothers" and at another time it will have the livery of "Bar > Buses." They're not variant > routes but variant operators. the basic options are different

Re: [Tagging] New Tag "Departures" voting results.

Nope. For example: https://www.openstreetmap.org/relation/3352395 The route us currently operated by two different operators on coordinated timetable and each operator have their own ETA system. While they do not provide a GTFS feed for now, it can be expected that each of them will provide their o

Re: [Tagging] New Tag "Departures" voting results.

On Thu, 7 Mar 2019 at 06:33, Martin Koppenhoefer wrote: > > > On 5. Mar 2019, at 21:33, Paul Allen wrote: > > > > Routes do exist with more than one operator. > > wouldn’t these simply be tagged as several relations? > I don't know. It's the same route, with the same service number, the same d

Re: [Tagging] New Tag "Departures" voting results.

sent from a phone > On 5. Mar 2019, at 21:33, Paul Allen wrote: > > Routes do exist with more than one operator. wouldn’t these simply be tagged as several relations? Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://li

Re: [Tagging] New Tag "Departures" voting results.

On Tue, 5 Mar 2019 at 19:07, Jarek Piórkowski wrote: > > Again, frankly - approximately zero general-purpose apps will support > whatever scheme we could come up with in OpenStreetMap to tag the > situation "this stop is served by a route that has two separate > timetables that are both valid, an

Re: [Tagging] New Tag "Departures" voting results.

On Tue, 5 Mar 2019 at 13:35, Paul Allen wrote: > But I'd prefer we have specific keys for > timetables and GTFS data rather than rely upon either of those. Much better > to make things clear > with timetable=* and gtfs=* (except we have to deal with partial > timetables/feeds from operators > w

Re: [Tagging] New Tag "Departures" voting results.

On Tue, 5 Mar 2019 at 17:37, Jarek Piórkowski wrote: > > If your use case is people using the query tool on > https://openstreetmap.org to follow links to PDFs to plan a journey, > Might be a PDF or a simple web page or a Web 2.0 page with funky effects and even live updates. Sadly, given the s

Re: [Tagging] New Tag "Departures" voting results.

Paul, If your use case is people using the query tool on https://openstreetmap.org to follow links to PDFs to plan a journey, then whatever tagging specification you use doesn't really matter as long as it's understandable to the people viewing it - a link looks like a link so that's quite easy. F

Re: [Tagging] New Tag "Departures" voting results.

On Tue, 5 Mar 2019 at 01:41, Jarek Piórkowski wrote: > > On Sat, 2 Mar 2019 at 19:42, Paul Allen wrote: > > As I said, I'd prefer not to use url=* because it could be for anything > - a page about the history of > > the bus stop (maybe the shelter is a listed building), > > That would rather be

Re: [Tagging] New Tag "Departures" voting results.

Hello, I've gotten paid for wrangling GTFS worldwide before - happy to tell you some of my experiences. On Sat, 2 Mar 2019 at 19:42, Paul Allen wrote: > As I said, I'd prefer not to use url=* because it could be for anything - a > page about the history of > the bus stop (maybe the shelter is a

Re: [Tagging] New Tag "Departures" voting results.

On Sun, 3 Mar 2019 at 00:06, Graeme Fitzpatrick wrote: > > On Sun, 3 Mar 2019 at 00:21, Paul Allen wrote: > >> On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote: >> >>> >>> So a documented way of including GTFS link in routes? >>> >> >> Yep. We could just use url=* >> > > When I'

Re: [Tagging] New Tag "Departures" voting results.

On Sun, 3 Mar 2019 at 00:21, Paul Allen wrote: > On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote: > >> >> So a documented way of including GTFS link in routes? >> > > Yep. We could just use url=* > When I've been adding bus stops, I've been using timetable= linked to the GTFS d

Re: [Tagging] New Tag "Departures" voting results.

On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote: > > So a documented way of including GTFS link in routes? > Yep. We could just use url=* but I'd prefer to keep that available for other things. Besides, it would probably be a good idea to allow for a link to the operator's time

Re: [Tagging] New Tag "Departures" voting results.

Mar 2, 2019, 9:12 AM by 61sundow...@gmail.com: > The other thing picked on it keeping it 'up to date'. > One says a route is out of date for years (why the contributor does not up > date it is not stated) > In my case: because updating it would take about half of hour, there are multiple ones

Re: [Tagging] New Tag "Departures" voting results.

On 02/03/19 10:27, Jarek Piórkowski wrote: On Fri, 1 Mar 2019 at 18:02, Leif Rasmussen <354...@gmail.com> wrote: It seems like the best way forward now is for a proposal allowing OpenStreetMap data to be tightly integrated with outside sources (such as GTFS) to be created by someone. +1. To

Re: [Tagging] New Tag "Departures" voting results.

On Fri, 1 Mar 2019 at 18:02, Leif Rasmussen <354...@gmail.com> wrote: > It seems like the best way forward now is for a proposal allowing > OpenStreetMap data to be tightly integrated with outside sources (such as > GTFS) to be created by someone. +1. To avoid lots of changes, perhaps only set t

[Tagging] New Tag "Departures" voting results.

Hi everyone, The proposal for the tag "departures" has finished, and has a final vote of * 12 "Approve" * 22 "Reject" * 3 Comments without vote * 1 "Degree of incredulity" at the proposal . . . meaning that the proposal was rejected. Overall, the main idea voters expressed was that connecting with

Re: [Tagging] New tag for major recipient postcodes

sent from a phone > On 22. Dec 2017, at 22:27, Rainer wrote: > > So it would be contact:addr:postcode_major_recipient nice, maybe we could add the issuer as well, e.g. contact:addr:deutsche_post_aktiengesellschaft:postcode_major_recipient ;-) seriously, something more concise would probably

Re: [Tagging] New tag for major recipient postcodes

Thinking about contact:addr:*, that sounds like a good idea. So it would be contact:addr:postcode_major_recipient Advantage is that it describes the purpose to be used for contacting the company, authority, hospital or whatever POI, but not e.g. for navigation, because it doesn't have a geogra

Re: [Tagging] New tag for major recipient postcodes

I think one mapping practice with contact:* could help . 1- addr:* tag space is for generic addresses, used by all consumers 2- if there is ambiguity between adresses (postal, physical, ...) then use several namespaces 2a - addr:* tag space for physical address (used by geocoding, routing, ...) 2

Re: [Tagging] New tag for major recipient postcodes

Hi, The British terminology for this is a 'non-geographic postcode'. I suggest that this terminology might make a more appropriate general tag because a) The purpose of the tag to indicate the non-geographic nature of the postcode, not the volume of post the address recieves and b) Special postcod

Re: [Tagging] New tag for major recipient postcodes

Am 17.12.2017 um 21:22 schrieb Warin: > As they are not related to a physical address then why use the address > space? The addr tag space is for postal addresses, that are not guaranteed to be physical at all (for example addr:city is the postal city, which might be completely un-surveyable). T

Re: [Tagging] New tag for major recipient postcodes

Hello, In stead of creating an additional tag and thus an additional country specific rule, why not using addr:full (or in the contact namespace if some prefer) to put this special addr that doesn't follow the standard country rule ? Regards, Marc Le 17. 12. 17 à 22:25, Rainer a écrit : > They

Re: [Tagging] New tag for major recipient postcodes

sent from a phone > On 17. Dec 2017, at 21:26, José G Moya Y. wrote: > > Obviously, phone numbers and email addresses are not "on the ground", so they > are just as out of scope of OSM as PO boxes/special zips are. I believe this is a very limiting view of both, the scope of OSM and the qu

Re: [Tagging] New tag for major recipient postcodes

They are used together with addr:city. The combination aoff addr:postcode_major_recipient and addr:city acts as an alias for addr:postcode & addr:city & addr:street & addr:housenumber. Am 17.12.2017 21:22, schrieb Warin: As they are not related to a physical address then why use the address s

Re: [Tagging] New tag for major recipient postcodes

El 17/12/2017 21:17, "Tom Pfeifer" escribió: On 17.12.2017 14:36, José G Moya Y. wrote: > > National-wide phone numbers treated (such as +1-800-x in USA, cellphones, > "vocal nomad" numbers (+34-51-xx in Spain, if I remember well) are > unlinked to physical addresses too. Are they directions ab

Re: [Tagging] New tag for major recipient postcodes

As they are not related to a physical address then why use the address space? Possibly the contact space? contact:mail:postcode=* - I believe 1800 numbers cannot be used internationally, so I don't use the ISD codes, that OSM requests, with these. On 18-Dec-17 12:36 AM, José

Re: [Tagging] New tag for major recipient postcodes

On 17.12.2017 14:36, José G Moya Y. wrote: Do you mean PO box? In some cities, massive PO boxes have a special Zip code/ postal code. It could be a property of the PObox address. It is kind of a postbox, but the mail might actually still be delivered by the carrier (and not picked from a box),

Re: [Tagging] New tag for major recipient postcodes

Do you mean PO box? In some cities, massive PO boxes have a special Zip code/ postal code. It could be a property of the PObox address. Maybe an attribute at the POI is right, as POI use to list email addresses and web addresses, which are independent from actual physical address (as PO boxes are)

Re: [Tagging] New tag for major recipient postcodes

As these postcodes are kind of a virtual address that is not tied to a particular pysical location, my opinion would be _not to add them to OSM_, which is a geo database and not primarily a post code reference database. Typically for those companies in DE, there is an additional physical addres

[Tagging] New tag for major recipient postcodes

Hi all, recently I came across postal codes in POI addresses, which aren't the classic scheme addr:postcode & addr:city & addr:street & addr:housenumber. However it is a special postcode that is assigned to recipients that receive a big amount of post every day, typically big companies or aut

Re: [Tagging] New tag

On Wed, Jun 29, 2016 at 11:27 PM, Hans De Kryger wrote: > How does everyone feel about (store_number=) for store numbers that > companies assign their stores? > I generally use ref=* for the store number. ___ Tagging mailing list Tagging@openstreetmap.

Re: [Tagging] New tag

2016-06-30 10:23 GMT+02:00 Colin Smale : > Are you suggesting that a shop object which is coterminous with a building > outline should get its own polygon, sharing nodes between the two? you could do it like this, but I'd rather use a multipolygon relation to avoid overlapping ways. Some people

Re: [Tagging] New tag

I apologize, i meant i would use (ref:shop=) just realized that. Read the tag as (ref:shop=number) But you guys have just won me over with your point of views. Will use (ref=) in my project, thanks! Regards, Hans Regards, Hans On Jun 30, 2016 12:59 AM, "Martin Koppenhoefer" wrote: > > 2016-06

Re: [Tagging] New tag

On 2016-06-30 09:51, Martin Koppenhoefer wrote: > If you put a ref on a shop it is clear that the ref refers to the shop. If it > isn't clear where the ref refers to (e.g. a building, another business or > amenity etc.) there is something wrong with the mapping and it combines > several objects

Re: [Tagging] New tag

2016-06-30 9:51 GMT+02:00 Martin Koppenhoefer : > ref=* and shop=* -- 10567 > ref:shop:num -- 121 > ref:shop --2 > and branch_ref -- 7 https://taginfo.openstreetmap.org/keys/branch_ref#overview Cheers, Martin ___ Tag

Re: [Tagging] New tag

2016-06-30 9:42 GMT+02:00 Andrew Errington : > ref=* would be better, as it's already understood by a lot of other tools > and renderers. +1, also, ref is already referring to a number, so ref:store:num seems unneccessarily complicated, so even if you should opt for a more structured tag than "

Re: [Tagging] New tag

ref=* would be better, as it's already understood by a lot of other tools and renderers. Andrew On 30 Jun 2016 16:28, "Steve Doerr" wrote: > On 30/06/2016 05:27, Hans De Kryger wrote: > > How does everyone feel about (store_number=) for store numbers that > companies assign their stores? > > > O

Re: [Tagging] New tag

On 30/06/2016 05:27, Hans De Kryger wrote: How does everyone feel about (store_number=) for store numbers that companies assign their stores? Or perhaps branch_number? -- Steve --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___

Re: [Tagging] New tag

(ref:shop:num) is what i plan on using. Just (ref=number) is not specific enough to me *Regards,* *Hans* On Wed, Jun 29, 2016 at 10:37 PM, Éric Gillet wrote: > 2016-06-30 6:27 GMT+02:00 Hans De Kryger : > >> How does everyone feel about (store_number=) for store numbers that >> companies assig

Re: [Tagging] New tag

2016-06-30 6:27 GMT+02:00 Hans De Kryger : > How does everyone feel about (store_number=) for store numbers that > companies assign their stores? > Why not use ref=* ? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/li

Re: [Tagging] New tag

Just found this https://wiki.openstreetmap.org/wiki/Key:ref:shop:num had to search the wiki a second time *Regards,* *Hans* On Wed, Jun 29, 2016 at 9:38 PM, Andrew Errington wrote: > Use ref=* > > Would that work? > > Andrew > > On 30 June 2016 at 13:27, Hans De Kryger > wrote: > >> How does

Re: [Tagging] New tag

Use ref=* Would that work? Andrew On 30 June 2016 at 13:27, Hans De Kryger wrote: > How does everyone feel about (store_number=) for store numbers that > companies assign their stores? > > > *Regards,* > > *Hans* > > ___ > Tagging mailing list > Tagg

[Tagging] New tag

How does everyone feel about (store_number=) for store numbers that companies assign their stores? *Regards,* *Hans* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag value in access? authorised [fork from: access in the wiki]

On Fri, Dec 5, 2014 at 11:34 AM, Martin Koppenhoefer wrote: > > > 2014-12-05 9:57 GMT+01:00 althio forum : >> >> Did you look at some of the examples in the links [7,8,9,10]? I feel >> "private" is not suitable there. >> How are tagged today the real-world "authorised vehicles" exemptions >> or si

Re: [Tagging] New tag value in access? authorised [fork from: access in the wiki]

2014-12-05 9:57 GMT+01:00 althio forum : > Did you look at some of the examples in the links [7,8,9,10]? I feel > "private" is not suitable there. > How are tagged today the real-world "authorised vehicles" exemptions > or signs with "authorised vehicles only"? > they are tagged as =private che

[Tagging] New tag value in access? authorised [fork from: access in the wiki]

/ DISCLAIMER / Starting new thread for side topics from: [Tagging] access in the wiki I would happily read more feedback from Martin and other contributors on "authorised" because it would certainly help with some limited traffic zone, bus lanes, residential streets... >> (2) proposing access=a

Re: [Tagging] New tag proposal Amenity=meditation centre

Serge Wroclawski wrote: > Christian Science Reading rooms have very little, if anything to do > with medication centers. > We aren't discussing medication centers, but rather meditation centers (or centres, to use the British spelling). -- John F. Eldredge -- j...@jfeldredge.com "Reserve you

Re: [Tagging] New tag proposal Amenity=meditation centre

Am 15.09.2012 um 15:56 schrieb Serge Wroclawski : > medication centers MediCation center ? ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag proposal Amenity=meditation centre

Christian Science Reading rooms have very little, if anything to do with medication centers. - Serge ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

[Tagging] New tag proposal Amenity=meditation centre

(reply to message at http://lists.openstreetmap.org/pipermail/tagging/2012-September/011278.html ) I am wondering whether this tag might be used for something like Christian Science Reading Room locations. Though not really a 'meditation center', such a location aims to provide an alternative

Re: [Tagging] New tag proposal Amenity=meditation centre

2012/9/2 Michael P : > Apologies for the newcomer defects, Im still trying to get the hang of wikis > and editing in opensteetmap. Any help would be appreciated if I can be shown > the mistakes and/or suggestions to improve my participation. > > I believe I created a new proposal discussion page at

  1   2   >