Re: [Tagging] FW: FW: Parking for businesses..
Agreed, although the situations in which it's not so clear are the ones where OSM could really get an advantage over the competition. So many times I'm directed by Google Maps to a location quite a distance away from the parking lot I'm trying to get to. It's especially annoying when there are one-way streets or divided highways which cause significant routing differences between a route directly to the location and a route to the correct parking lot. I'll smile when my GPS tells me to drive to X, park, walk across the pedestrian bridge etc. Even moreso if it's done using OSM data. I have to agree; the huge bonus with OSM is the level of detail that we can achieve with it. Also being able to start embedding not as obvious knowledge into the mapping data is a huge plus. Lol, now just think if we micro-mapped each tree in the parking lot you could get your GPS to determine the spot that is likely to be in shade for a large part of the day, keeping your car nice and cool! :) Ok, too far perhaps. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: FW: Parking for businesses..
Rather than permitted=*, why not use parking_use=*? That would then be consistent with your proposed relation. Though permitted is more general and might be able to be generalised to other features... Or perhaps something like permitted_parkers; I don't think there's anything wrong with a somewhat specific tag like that. It'll prevent ambiguity in the future such as what we're trying to resolve here with the access one. :) I suggested a similar solution a couple of days ago: Alternatively, for parking, use the key use (as a noun) instead of [or in addition to] access, as in use=public/customer/private. There are then a few options for defining the values of parking_use, e.g. my public/customer/private or your patron/staff/permit_holder, or some combination thereof... Ooops, yes, you did. Great idea! :) So many emails, so little time. Agreed; similar words to mean similar things. I opted for patron rather than customer so that it was a little more generic; it sounds a little funny to say patient parking for a doctor is customer parking. :) Patron is a little more generic I think. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: FW: Parking for businesses..
On 20 May 2010 22:46, Tyler Gunn ty...@egunn.com wrote: Lol, now just think if we micro-mapped each tree in the parking lot you could get your GPS to determine the spot that is likely to be in shade for a large part of the day, keeping your car nice and cool! :) Ok, too far perhaps. Some people do map individual trees complete with latin names for the plant. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: FW: Parking for businesses..
On Thu, May 20, 2010 at 8:50 AM, John Smith deltafoxtrot...@gmail.comwrote: On 20 May 2010 22:46, Tyler Gunn ty...@egunn.com wrote: Lol, now just think if we micro-mapped each tree in the parking lot you could get your GPS to determine the spot that is likely to be in shade for a large part of the day, keeping your car nice and cool! :) Ok, too far perhaps. Some people do map individual trees complete with latin names for the plant. I saw some of the larger trees modeled in the winner of the Google 3D Model Your Town contest. I'd say something like that is realistic at the point where making a 3D model is as simple as taking a video and letting a computer figure everything out. Probably not too far, but a little bit ahead of its time. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: FW: Parking for businesses..
Yes, exactly. I couldn't have put it better myself!! From: tagging-boun...@openstreetmap.org[mailto:tagging-boun...@openstreetmap.org] On Behalf Of Anthony Sent: 19 May 2010 21:36 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] FW: Parking for businesses.. On Wed, May 19, 2010 at 3:15 PM, Seventy 7 seven...@operamail.com wrote: I'm looking at a city centre I'm going to visit, I'm lookingout for blue Ps. I don't really care if they're commercial car parks or not. So you want access=public (publicly owned parking) or access=permissive(commercial car parks which allow general access, possibly for a fee). Mapping the areas around shopping centres? Just make themyellow! I know they'll have car parking, they always do. Does the sports club I'm visiting have a car park? It goes without saying theyare for members and visitors. Just make them yellow! Access=private works fine, then (along with access=public andaccess=permissive). Preferably with an additional tag (or relation) withsome indication of who is allowed to park there. Maybe access=customer isn't needed after all. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: FW: Parking for businesses..
Access=private works fine, then (along with access=public andaccess=permissive). Preferably with an additional tag (or relation) withsome indication of who is allowed to park there. Maybe access=customer isn't needed after all. How about something like: access=private permitted=patron/permit_holder/staff There's probably other valid permitted types, but this organization would handle the following types of situations quite well: - Public parking lot (ie you come here and pay to park, regardless of where you're going): access=permissive - Store parking lot for customer: access=private, permitted=patron - Store parking lot for staff only: access=private, permitted=staff - Parking lot for monthly parkers: access=private, permitted=permit_holder A relation to define what businesses are served by the lot could be something like: type=parking_use Where you'd have member roles: lot: a parking lot(s) for_use_by: the business(es) that the parking is intended for. I think in most circumstances it is probably pretty clear which business a parking lot is intended for though. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: FW: Parking for businesses..
On Wed, May 19, 2010 at 5:36 PM, Tyler Gunn ty...@egunn.com wrote: I think in most circumstances it is probably pretty clear which business a parking lot is intended for though. Agreed, although the situations in which it's not so clear are the ones where OSM could really get an advantage over the competition. So many times I'm directed by Google Maps to a location quite a distance away from the parking lot I'm trying to get to. It's especially annoying when there are one-way streets or divided highways which cause significant routing differences between a route directly to the location and a route to the correct parking lot. I'll smile when my GPS tells me to drive to X, park, walk across the pedestrian bridge etc. Even moreso if it's done using OSM data. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] FW: FW: Parking for businesses..
On Thu, May 20, 2010 at 7:36 AM, Tyler Gunn ty...@egunn.com wrote: Access=private works fine, then (along with access=public andaccess=permissive). Preferably with an additional tag (or relation) withsome indication of who is allowed to park there. Maybe access=customer isn't needed after all. How about something like: access=private permitted=patron/permit_holder/staff There's probably other valid permitted types, but this organization would handle the following types of situations quite well: - Public parking lot (ie you come here and pay to park, regardless of where you're going): access=permissive - Store parking lot for customer: access=private, permitted=patron - Store parking lot for staff only: access=private, permitted=staff - Parking lot for monthly parkers: access=private, permitted=permit_holder A relation to define what businesses are served by the lot could be something like: type=parking_use Where you'd have member roles: lot: a parking lot(s) for_use_by: the business(es) that the parking is intended for. I think in most circumstances it is probably pretty clear which business a parking lot is intended for though. Rather than permitted=*, why not use parking_use=*? That would then be consistent with your proposed relation. Though permitted is more general and might be able to be generalised to other features... I suggested a similar solution a couple of days ago: Alternatively, for parking, use the key use (as a noun) instead of [or in addition to] access, as in use=public/customer/private. There are then a few options for defining the values of parking_use, e.g. my public/customer/private or your patron/staff/permit_holder, or some combination thereof... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
