Multi-dentist office

[Matija_Nalis]

@SK53

Given that they share an office I would imagine the opening hours & phone are likely to be the same, and also that there will be a single generic email

I agree about phone (as there would usually be one receptionists handling all of them), but I’d surely thought in majority of cases they’ll have different opening_hours.

One of the major reasons for them to share the same space is likely to cut down on costs, and having all dentists works at the same time is a waste of at least 50% (or more) of resources. (e.g. if you have 10 dentists, you can can have only 5 rooms and have 5 dentists work in the morning shift, and 5 dentists work in afternoon shift; which is much cheaper than e.g. having to have 10 rooms and all dentists work only in the morning shift)

So I’d guess in majority of the cases (at least down here) you’d have to map each of them as separate node (regardless of possible grouping them in some extra polygon or relation)

[SK53]

@Matija_Nalis

One of the major reasons for them to share the same space is likely to cut down on costs, and having all dentists works at the same time is a waste of at least 50% (or more) of resources.

I’d be surprised if this was the actual case, but only based on UK dentists who often seem to have more than one working room even for one dentist. However, this is absolutely the case for doctors consulting offices where the doctor is a specialist. They may run one session a week or month from a particular office, and many doctors will be using the same facility.

As I’ve said before I think trying to capture all this information may be overkill on OSM, and potentially a maintenance nightmare. On the other hand if dentists and doctors want to maintain their own information (and a friend & neighbour did just that for his private clinic - or rather his social media person did) then splitting things up makes sense. Right now I’d approach it pragmatically: single element, tagged as in @Minh_Nguyen’s example; and then move to multiple elements IFF differences such as opening hours become important.

[Fabi2 (Fabian)]

This can be done with the “outdated” (yes, some people marked it as such in the wiki) Healthcare 2.0 proposal. Look at this dentist for an example.

[Matija_Nalis]

@Fabi2

Look at this dentist for an example.

Umm, is that correct link? I see no multiple dentists tagged at that way (at least in latest revision #8 from a month ago)?

[Fabi2 (Fabian)]

@Matija_Nalis

Umm, is that correct link? I see no multiple dentists tagged at that way (at least in latest revision #8 from a month ago)?

Have you looked at the relations on this object?
Even as these relation solution make it harder (this is why I also have a simple solution, but with the features/primitives, now supported by OSM/the API, I found no better solution), if you add additional map objects e.g. nodes, then data consumes don’t know, that they belong together.

My proposal was constructed with the fact in mind, that in many cases, the service of medical facilities (which also depends on personal experience) can only be good described, when you tag the qualifications of the persons working there.

But this relation solution may also useful for things such as offices into a health centres, where you can a relation for each office using health_facility:type=office instead of heralth_person:type=*.

Edit: Persons have no geometry (so they also shouldn’t in OSM) and the object relationship-tree (e.g. an health centre mapped as node contains some offices, with different kind of people working in them) in OSM can only be represented by relations. Only if you need an idea from me for API 0.7, then this object linking and different logical objects on the same physical location (e.g amenity=cafe/restaurant or amenity=bar/restaurant, …).

[IanH]

@Fabi2

But this relation solution may also useful for things such as offices into a health centres, where you can a relation for each office using health_facility:type=office instead of heralth_person:type=*.

I like the facility:type=office to describe medical offices. Why do the offices need be grouped. The cost of duplicating the tags in common is a much simpler solution than a including them in a relation.

[Nadjita]

I know it can be done with Healthcare 2.0, and I’m sad to see it marked outdated, because it was a good schema for exactly this purpose

[Fabi2 (Fabian)]

@IanH

I like the facility:type=office to describe medical offices. Why do the offices need be grouped. The cost of duplicating the tags in common is a much simpler solution than a including them in a relation.

I only wanted to mention, that it is possible, if required. Using relations should be avoided, if not required (this is also written in the proposal), as they make the editing harder. But if you for example have tagged a health centre on a node and/or can not get the exact positions of the offices, then you can add them as relations. Refer to the tag pages, if they exist, as I or others have added new subkeys.

[IanH]

@Fabi2

if you for example have tagged a health centre on a node and/or can not get the exact positions of the offices, then you can add them as relations.

What is the use case for a large number health centers as nodes which are then grouped together with a relation? The whole thing seems bit self-defeating even by your own description of it. The most obvious problem being an immediately lose of fidelity by using a node instead of using buildings. The best you can do is to list all seevices in a building. Such as all the specialities that have offices. I just don’t see the benefit of condensing buildings when they take up real space on the map.

[Matija_Nalis]

@Fabi2

Have you looked at the relations on this object?

No, not until you mentioned it It is a strange schema. Multiple dummy relations, with each having one (the same!) element? Isn’t that exactly opposite of how relations should be used (i.e. one relation with multiple nodes as elements)?

@Fabi2

if you add additional map objects e.g. nodes, then data consumes don’t know, that they belong together.

I’m still not convinced… If there are multiple dentists in one building, then the data consumer would know that by their geometries alone. You can even micromap the rooms and corridors if you feel like mapping such information in useful. But what is the use case where data consumers would want to know their exact business arrangement of the dentists and who pays what part of the bill (and what about many other cases or related businesses, e.g. multiple dentists who have same owner but are situated at multiple locations in the city)?

@Nadjita

I know it can be done with Healthcare 2.0, and I’m sad to see it marked outdated

Where is it marked “outdated” though? I see https://wiki.openstreetmap.org/wiki/Proposal:Healthcare_2.0 has status “inactive” which is correct (RFC started in 2011 and never progressed to vote, if you talk about that? Are you interested in picking it up to reactivate it?)

[Minh_Nguyen (Minh Nguyễn)]

@Matija_Nalis

It is a strange schema. Multiple dummy relations, with each having one (the same!) element? Isn’t that exactly opposite of how relations should be used (i.e. one relation with multiple nodes as elements)?

It is an unusual use of relations but not necessarily an invalid modeling. In some other contexts, I have considered experimenting with adding an element to multiple single-member relations, as a workaround for the data model’s lack of support for setting a key to an array of key-value tables.

For example, if a flagpole flies multiple flags, the details about each flag could be consolidated into a single-member relation instead of being distributed among multiple semicolon-delimited flag:* tag values. There could be similar benefits to the destination:* and parking:* tagging schemes.

Unfortunately, in these cases, I think the multiple-relation approach is a nonstarter, because it isn’t possible to arrange the relations in a particular order. A relation can indicate the order of its members, but a node can’t indicate the order in which its containing relations should be listed. In the case of street parking restrictions, it isn’t possible for one relation to override aspects of another relation. The public transit tagging scheme is working around this issue with a route_ref key, but it’s a bit of a kludge.

In the case of a shop or office that has multiple identities or multiple colocated businesses without any spatial distinction, maybe the ordering issue isn’t relevant. However, it would be difficult for data consumers to adjust to such a drastically different method of mapping point features. Some OpenHistoricalMap contributors have experimented with this kind of tagging, but it’s been a challenge to support it in editors, renderers, etc.

[dieterdreist]

For example, if a flagpole flies multiple flags, the details about each flag could be consolidated into a single-member relation instead of being distributed among multiple semicolon-delimited flag:* tag values. There could be similar benefits to the destination:* and parking:* tagging schemes.

oh yes, this is also a usecase for the type=node relation, where you could e.g. have a node with man_made=flagpole and “attach” the flags with relations (generally its usecase is several “node”-like things on the same spot).

[dieterdreist]

A relation can indicate the order of its members, but a node can’t indicate the order in which its containing relations should be listed.

vertical ordering can be expressed as always with the layer tag

[IanH]

Still not sure what the need for relations. The dentist’s names should already appear in the list of ower/operators for the office. Doctors usually have some type financial or management role in the practice where their office are located. So with the addition of a few healthcare related tags, the tag representing the office information should be enough to answer any questions about the doctor who practice in it. Micromap each dentist’s office in the build If location is that important.

[Minh_Nguyen (Minh Nguyễn)]

A less esoteric approach might be multiple coincident nodes with layer tags. If necessary, they can be joined by a site relation (or some other relation type for pole-mounted point features). But I agree with @IanH that an approach that relies on relations is probably more trouble than it’s worth for most of these things.

[Fabi2 (Fabian)]

@IanH

@Fabi2

if you for example have tagged a health centre on a node and/or can not get the exact positions of the offices, then you can add them as relations.

What is the use case for a large number health centers as nodes which are then grouped together with a relation?

Consider this case, which is very common in Germany:

You have a health centre inside the same single building, with multiple independent offices inside the health centre. Some of the offices may be operated by more then one physician and may have additional staff such as e.g. special prophylactic therapists. Physicians of the same office, even when their main specialty is most times the same, differ in their additional training.

Now you have only a picture of the board in or outside the building, with a sign for each office on it. On each sign the name of the operating physician and the specialty of the office, contact data such as phone and website and openeing hours are written. You have no data from inside the building and just took the picture of the board and now have the data of the say around ten offices inside the health centre. For many offices you can find detailed information about the staff and training of the physicians of the office on the website.

Now want to map all the offices inside the building, their staff including the specialties and the rceived (additional) training, besides common contact data and opening hours of the offices.

As the API/data model, until now, has no clean logical tag seperation for more then one object on the same location/possition or for logical object linking, you have to (mis)use relations as container for logical separation and stacked trees of relations for logical object linking as a (complicated) workaround.

With now used common “:”-namespaces you will get many different keys for the same thing, depending of the type, or other context information, of the affected main map object.

As the my proposal was written, I thought only about the special case of the health care system, but later had nearly the same problem, but less complicated, with office=lawyer. For now, somone should write a proposal for a generic type=person_role relation (first test of the idea) and one for a generic type=multifeature relation.

@IanH: In Germany we have physicians called “Hausarzt”, which are trained for internal medicine (which requires the formal training for family medicine), but are working as physicians for family medicine. Besides this, there are also physicians, which are trained for family medicine only. They are both tagged with healthcare:speciality=general now, but the physician of internal medicine has more knowledge, e.g. in case of an emergency. In some bigger offices of family medicine you may find some of each type working in the same office.

@Minh_Nguyen:
Creating multiple nodes implies that they don’t belong together or that it may look as you are having the location data of the objects (You can try to reliable parse the fixme=*-keys on the objects ).

[Minh_Nguyen (Minh Nguyễn)]

@Fabi2

Creating multiple nodes implies that they don’t belong together or that it may look as you are having the location data of the objects (You can try to reliable parse the fixme=*-keys on the objects ).

Yes, this is indeed a tradeoff of using multiple nodes. However, I think it’s preferable to point relations that few editors or data consumers would understand. Ideally we’d make an effort to ascertain the relative locations if there are fixed locations, but in the meantime, the health center should be mapped as an area that contains all the nodes. If all the providers share the same space, I suppose you could represent a superposition by mapping each provider as an area that shares the same nodes with the health center.

[Fabi2 (Fabian)]

@Minh_Nguyen

@Fabi2

Creating multiple nodes implies that they don’t belong together or that it may look as you are having the location data of the objects (You can try to reliable parse the fixme=*-keys on the objects ).

Yes, this is indeed a tradeoff of using multiple nodes. However, I think it’s preferable to point relations that few editors or data consumers would understand.

All new tagging proposals are in most cases first not understood by data consumers or have editor suppport. For the many simple cases, I have also proposed a simple version. But we don’t should try to map the reality, because it will be to complicated to add editor support or fix the API.

@Minh_Nguyen

Ideally we’d make an effort to ascertain the relative locations if there are fixed locations, but in the meantime, the health center should be mapped as an area that contains all the nodes

Even if you set a e.g. “fixme=position estimated”-node for each office in the area of the health centre, you have the problem of representing the different staff of the offices. Provided service level of physician offices and healthcare facilities in general depands on the training of the staff!

For lawyers it depands on working experience and in Germany, we now have new formal training for some fields/specialties as a new created addon-training.

@Minh_Nguyen

If all the providers share the same space, I suppose you could represent a superposition by mapping each provider as an area that shares the same nodes with the health center.

Until now, I have not found the hotkey for an easy selection of the right object version of multiple 100% overlapping/stacked area- or line objects in iD. Maybe I should try harder to find it.

[Minh_Nguyen (Minh Nguyễn)]

@Fabi2

All new tagging proposals are in most cases first not understood by data consumers or have editor suppport. For the many simple cases, I have also proposed a simple version. But we don’t should try to map the reality, because it will be to complicated to add editor support or fix the API.

This is true, but some proposals are more invasive or disruptive than others. Even if a proposal to formalize the mapping of any kind of POI on “multifeature” relations were to pass, its uptake rate by editors, QA tools, and data consumers would not be very satisfying. It would be especially difficult to gain software support if the proposal is limited to a relatively small number of POIs, due to the amount of work required to consume this novel, nongeometric relation type.

@Fabi2

Until now, I have not found the hotkey for an easy selection of the right object version of multiple 100% overlapping/stacked area- or line objects in iD. Maybe I should try harder to find it.

In iD, you can press ? to see a list of keyboard shortcuts:

Selecting the parent ways of a node shows all the ways in a list in the sidebar. Superpositioned areas aren’t particularly intuitive – yet another tradeoff. Personally, I would either rely on semicolon-delimited values or, where it gets too messy, place nodes alongside each other, accepting the imprecision under the KISS principle. But if you consider spatial precision to be a higher priority than practical software support, then I say: any relation type you like.

[IanH]

Sorry, let me rephrase my comment.

Why are multiple individuals being all mapped on a node. The example of professional offices (example uses doctors and lawyers) is trying to compress a large practice, clinic or large area into a single node. Most professional don’t work that way if only for basic privacy requirements. Even when one is shared, an office can be represented by adding the list of occupants who commonly share it during the week.

It is rare that more than three individuals will use particular office. If the practice is that small, the professional specialities should also be a list at the next level such as the building part for the suite, building, or POI node itself.