Re: [Tagging] Feature Proposal - RFC - Kitchen hours
On Thu, Feb 9, 2012 at 4:32 AM, Daniel Herding wrote: > Hallo everyone! > There are many restaurants etc. that close their kitchen early in the > evening. Afterwards, you can no longer order hot food, only drinks and cold > snacks. Similarly, at some restaurants the kitchen opens at noon, but you can > already go there earlier and order e.g. coffee and muffins. > I think that we should include this information in OpenStreetMap. Here is my > proposal: > http://wiki.openstreetmap.org/wiki/Proposed_features/Kitchen_hours > Please comment the proposal on its discussion wiki page. I wonder if this couldn't be made a bit more generic to encapsulate other time-frames within an establishment's opening hours. For example in a restaurant: opening_hours=Mo-Fr 08:00-23:00 opening_hours:breakfast=Mo-Fr 08:00-10:00 opening_hours:lunch=Mo-Fr 11:00-13:00 opening_hours:supper_buffer=Fr 18:00-20:00 This would allow a mapper to highlight important time constraints relevant to a particular business. Imagine also a public swimming pool: opening_hours=Mo-Fr 10:00-20:00 opening_hours:public_swim=Mo 18:00-20:00;We 18:00-20:00;Fr 18:00-20:00 I'd propose that the sub-tags could really be anything a mapper finds important to an establishment. When displaying the details for an establishment, I could imagine displaying a "timeline" for the current day, shading in the general opening hours, and then putting a little bar in rows below to highlight the "important" time spans within the current day. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made
On Sun, Feb 19, 2012 at 8:13 AM, Amanda wrote: > hello! > new here. don't know if it's the right place to address this issue, sorry if > i'm mistaken.. > my suggestion is: MAN MADE should be called HUMAN MADE I think in this context, the reference to MAN is referring to the human individual as representing the species, without referencing gender. Beside, human contains MAN so I think we're ultimately splitting hairs here. Ultimately the fact the tag is called "man_made" isn't really important though; its just a logical category used to group related items. These tag names are typically used by the map renderer, for example, to determine which icon should be shown on the map, etc. So when this data is consumed we'll typically see these values go away anyways. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Ways that change names while crossing divided roadways
I installed the Garmin OSM map for my area and have been using it while I drive around locally. The one thing I've noticed is that there is a lot of inconsistency in how streets that cross divided roadways are named. For example: http://osm.org/go/Wpz_F8RFl- Note Sunset Blvd on the left and Crystal Avenue on the right. Crystal crosses all the way over to the left roadway. As a result, going south down the divided roadway, the Garmin picked up Crystal as the cross street, when I think it probably should have picked up Sunset. I'm thinking the solution would be to split the small way segment between the major roads so that the naming can carry across the major roadway. Make sense? Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Relation for addresses far from the street
I'm slowly filling in the local "mega-retail complex" near me: http://www.openstreetmap.org/?lat=49.82432&lon=-97.20558&zoom=17&layers=B000FTF Its a pretty large area, and there are a load of businesses and shops within the area. All of the roads in the area are for the commercial development only; ie not named streets. Thus all of the businesses have an official address on the main road, "Kenaston Boulevard". Take "Wok Box" for example; I've added all the addr: tags to indicate its address. I was about to create a relation for the address information (http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Using_Relations_to_associate_house_and_street_.28optional.29) but then got to wondering what I should associate the POIs to. I mean TECHNICALLY the street address is Kenaston Boulevard, but the POIs are really so close to the service roads, I wonder if I should make the relation to there? Thanks! Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cleaning up
On Wed, 5 May 2010 17:55:10 +0200, Pieren wrote: > What inevitable ?. I think that drawing sidewalks is silly and waste of > time. Let say that 99.99% of the unclassified and residential roads can be > walked on both sides, why should we draw the sidewalks everywhere ? It > would > be more clever to tag where sidewalks are missing or not allowed, imo. Say > where things are missing, not where they are obviously authorized. Or you > add "oneway=no" to all roads as well ? In my area, sidewalks are most certainly NOT the norm. There are very few of them, and where they are present they are typically separated from the road by a boulevard. Other areas of my city have sidewalks that are right up against the roads. I can see the merit of representing sidewalks that are right up against the road by using an attribute on the road. However for sidewalks separated from the road by a boulevard I'd think it makes more sense to draw them in as separate paths. Just my 2c. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cleaning up
> +1. Micromapping may be "on the rise", but that doesn't mean it's > necessarily a good thing. I'd still like to see a means of specifying, on > administrative boundaries, tags that are to be assumed (inherited) by > contained objects (e.g. sidewalk=yes, surface=paved, lanes=2, maxspeed=25 > mph, etc.). I currently don't tag these, but it would be useful to > visitors > to know them. I agree that it'd be nice to be able to set defaults for an area such as typical speed limits. I guess it depends what you consider micromapping... Here's an area in Google Maps: http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Winnipeg,+MB&sll=37.0625,-95.677068&sspn=45.957536,64.951172&ie=UTF8&hq=&hnear=Winnipeg,+Division+No.+11,+Manitoba,+Canada&ll=49.823878,-97.201324&spn=0.009192,0.024033&z=16 Here's the same area in OSM; I've added a lot of detail to this shopping district including parking lots, buildings, and started to put in POIs. I think this is a HUGE improvement over what Google Maps shows: http://www.openstreetmap.org/?lat=49.82372&lon=-97.20104&zoom=16&layers=B000FTF Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cleaning up
On Thu, 6 May 2010 12:37:10 +0200, M∡rtin Koppenhoefer > +1, nice. > cheers, > Martin It definitely shows how incredibly pedestrian-unfriendly these big suburban box store "malls" are. There are buildings in a sea of parking lots. Lol. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Parking for businesses..
I was using the OSM maps for my city on my Garmin recently and when I listed the "parking" POIs I noticed a whole slew of parking showing up in there; mainly "unnamed".. It got me thinking why those are in there but then it dawned on me that in my area I've started adding in the parking lots and service roads for businesses in my area: http://www.openstreetmap.org/?lat=49.790516&lon=-97.156395&zoom=18&layers=B000FTF This brought up a few questions: 1. What should the "access" for these parking lots be? access=public would seem to be appropriate, but in some regards that's not entirely accurate. Almost all of these types of parking lots will have some kind of notice that tow-away is enforced for unauthorized parking. So the general idea is you're free to park there, ONLY if you're visiting the businesses serviced by the lot. So would access=permissive (The owner gives general permission for access.) or access=destination (The public has right of access only if this is the only road to your destination.) be more appropriate? 2. Should I bother naming these parking lots? Thanks! Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Parking for businesses..
> From http://wiki.openstreetmap.org/wiki/Parking: > "The distinction between public parking lots, customer parking lots > (such as at cinemas etc.), and private parking lots (such as for staff > in a business park) is handled with access=* tags." > To me, reading that directly that would seem to suggest using one of > three values: > access=public, or > access=customer, or > access=private. > Of these, in your case you would clearly use access=customer. > But there may be other opinions out there. Ideally, we do want to make > sure the documented access=* values for parking are 1) verifiable, 2) > mutually-exclusive, 3) useful. According to OSMDoc and Tagwatch there are a handful of access:customer tags out there, and maybe 100 access:customers. So it's clearly not an accepted value yet. I'd agree with the 3 values you proposed though; really access=customer is the only new one. Makes sense to me too because it allows for a true distinction between general public parking (like multi-story parkades that are in the business of parking cars regardless of where the people are going), and parking lots intended to service the customers of a store, business, etc. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Parking for businesses..
> I was thinking access=destination although then you need to link the > parking lot to the destination, although you probably would for > access=customer as well since you might need to know where to spend > money, or window shop, to be considered a customer. I like this; access=destination definitely holds the right meaning for parking in front of a store as it is intended only for those whose destination is that particular store. I couldn't find any existing relations to link things in this manner though. Does anyone know of any examples of parking lots tagged in a manner similar to this? Thanks! Tyler ___ 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..
> 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] ID Permanence
On Thu, 3 Jun 2010 15:47:14 +1000, John Smith wrote: > I've penned some initial thoughts on what to do about Object ID Permanence > http://wiki.openstreetmap.org/wiki/Proposed_features/UUID Hi John, Being a programmer I understand what a UUID is and have used them many times. I am, however, curious what use you are envisioning for this UUID data? Are you thinking of external sites that would want to reference OSM data directly? Just curious... Thanks, Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tagging individual properties?
I'm curious, what would be the best way to tag the boundaries of individual properties? Or SHOULD I even attempt this? The Cadestral data for Manitoba is available from the Manitoba Lands Initiative under a free for use license, so I was thinking of incorporating this data. I've converted a bit of the data, opting to merge all the lots into larger blocks to indicate the landuse of residential, park, etc. It's kinda nice because it also gives you a guide for aligning the roads; they should typically be in between the landuse areas. I think it looks pretty decent with the houses I added in from Yahoo: http://www.openstreetmap.org/?lat=49.775024&lon=-97.170408&zoom=18&layers=M However, in areas where there is no satellite imagery available to put in the houses, I feel that NOT identifying the boundaries of each lot really gives up on what could be valuable information; knowing the boundaries of each lot would be a great navigational aid. http://www.openstreetmap.org/?lat=49.78962&lon=-97.164207&zoom=18&layers=M I tried just importing the data straight in where each lot was it's own multipolygon (lots of shared boundaries) with landuse=residential. However when rendered in Mapnik and osmarenderer, it just came out as a solid colored area with no indication where the lots are. Perhaps I would need to mark the ways some how? Just trying to think how to get the data to show up. If it doesn't show up then my current approach of just marking the landuse using this data is sufficient. Opinions? Tyler -- -- Tyler Gunn ty...@egunn.com ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging individual properties?
> A way to do this would be to map any fence lines marking the boundaries. That's a possibility. Though I have no way to be sure where the fences extend to in the front half of the properties. Probably not worth it now that I think of it. > Have you checked it for accuracy? The DCDBLite data for Qld had ok > accuracy in some areas, but in others it has lots and lots of mistakes > and out of date information and incorrect positioning. So far the data seems pretty accurate. It's the IDENTICAL data that is on the city's website, which lines up perfectly to the high resolution (<1m) aerial imagery they have of the entire city. When I brought it over into OSM as large "landuse blobs", it straddles the existing OSM streets quite nicely. > We ended up using the DCDB data here to map other features like > railway lines and waterways, rather than the property boundaries > themselves. The railway lands and park boundaries are another great use of this data. Especially given how out of date the satellite imagery of my city is. :) > Depending on the quality of the data it may be a very bad thing to do, > this is typically referred to as implopping and with everything else > everyone wants to map the bad data is never touched or updated and > left to rot. > > If this is mainly for your own use, you may be better converting it to > KML or your own pgsql DB and making a transparent layer, rather than > putting it directly into the OSM DB. Yeah, the more I think of it, the less I want to use this to mark property boundaries. I think I'll stick with just deriving the landuse areas out of it and be done with that. It's still a great source of information in that respect. Thanks, Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Waterway direction
> Why shouldn't it? Probably depends on the situation, but if the occur > on an object that we generally tag with waterway, it should be clear. > This technique was already used in ancient Rome for special parts of > aqueducts (where they had to bypass an obstacle). Aren't they a kind > of culvert? Btw.: I just found out that in the case of wastewater this > is called a depressed sewer in English. There's actually an inverted siphon here in Winnipeg. It's used to allow the Seine River to pass UNDER the red river floodway: http://maps.google.com/maps?f=q&source=s_q&hl=en&q=Seine+river,+Tach%C3%A9,+Division+No.+2,+Manitoba+R0A+0X0,+Canada&sll=37.0625,-95.677068&sspn=43.664131,78.310547&ie=UTF8&cd=1&geocode=FQj69QId6_85-g&split=0&hq=&hnear=Seine+river,+Tach%C3%A9,+Division+No.+2,+Manitoba+R0A+0X0,+Canada&ll=49.79002,-97.047815&spn=0.017455,0.038238&t=h&z=15 The meandering river in the middle of the frame seems to dissapear and reappear in the middle of the frame. In reality the river flows into a concrete box, under the floodway, and then comes up and out the other side. Tyler ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Boundaries for suburbs
What is the "proper" way to tag a boundary for a suburb? I'm trying to avoid using "place=suburb" nodes as they don't accurately capture the boundaries of the neighbourhoods I'm attempting to map. I've been playing around with this in my area and came up with two examples: Example One: - "place=suburb" node central to neighborhood: http://www.openstreetmap.org/browse/node/1168219909 - Boundary relation with the the "place" node marked as a label: http://www.openstreetmap.org/browse/relation/1438874; included the place attributes on the boundary as well. Not sure if required. An example of how I've attempted this is as follows. At this zoom level, Mapnik correctly renders a label for the suburb, http://www.openstreetmap.org/?lat=49.80617&lon=-97.18193&zoom=16&layers=M Zooming in once more reveals TWO labels for the area: http://www.openstreetmap.org/?lat=49.80617&lon=-97.18193&zoom=17&layers=M See above links for the node and relation in my example. It's clear that when you zoom in the larger label is from the place node, and the smaller one is from the boundary itself. Mapnik seems to render appropriately. Example Two: Another attempt I made used the scheme: - "label" node central to the neighborhood: http://www.openstreetmap.org/browse/node/499644122 - Boundary relation with just administrative level stuff in it: http://www.openstreetmap.org/browse/relation/1438875 Here you can see that the neighborhood label renders much smaller http://www.openstreetmap.org/?lat=49.81031&lon=-97.16204&zoom=15&layers=M I'm inclined to think that example Two is more correct, but I have to say I like the larger more prominent labels of Example One. I know, probably not good to map for the renderer. Opinions are appreciated! THanks! Tyler -- Tyler Gunn ty...@egunn.com http://www.egunn.com/ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Boundaries for suburbs
> I don't think boundary=administrative is appropriate. I'd use > landuse=residential name=* with no other tags for a simple subdivision. This > ends up rendering reasonably: > http://www.openstreetmap.org/?lat=28.4285&lon=-81.4944&zoom=14&layers=M These are civic recognized sub-areas and neighbourhoods of my city, often times with varying land uses within. I don't think the landuse=* is appropriate. I see how the example you're shown works though; I can just see it getting ugly as you can't characterize the landuse of an entire section of the city as one. Thanks, Tyler -- Tyler Gunn ty...@egunn.com http://www.egunn.com/ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Boundaries for suburbs
> is the approximative way to place a label and is rendered by mapnik > is IMHO the "correct" way to do it, but is not recognized by Mapnik. > This is an result of Mapnik rendering the node as a label and > rendering the name of _any_ area at high zoom levels. It doesn't > recognize the boundary relation, but it renders all polygons and > therefor _also_ the boundary relations. So it would seem the place node itself is redundant then. It should just be used as a label. Perhaps I'll have to download and install Nominatim to see how it handles things too. Ultimately for display purposes it's one thing, but I'd like these relations/boundaries to be useful and unambiguous when it comes to determining where a particular location is. Thanks, Tyler -- Tyler Gunn ty...@egunn.com http://www.egunn.com/ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - daycare
You say: "A place for children to do homework, play and spend time otherwise after school." The "after school" part is inaccurate as day care centers are often a place children go to during the day while their parents work. Some other considerations: - Type: - centers: larger in size, with multiple employees caring for a larger number of children. - home-based: an individual watching children in their own home. - Frequency of care offered: Full-time (ie children attend every day on fixed schedule), part-time (ie less than full-time), before and after school (as a service to working parents whom leave for work and arrive home from work before and after the regular public school day) - The existing opening_hours tag is useful information that someone could specify for a daycare. - Age ranges are important (ie some care for only school age children, where others specialize in pre-school, infants, etc). On Thu, Apr 21, 2011 at 10:13 AM, Flaimo wrote: > created a proposal for amenity=daycare: > > http://wiki.openstreetmap.org/wiki/Proposed_features/daycare > > more information on wikipedia: http://en.wikipedia.org/wiki/Daycare > > flaimo > > ___ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
