Add an area_size key

[gidsi]

I just realized that one of the, for me, very interesting information is missing. It gives me a rough estimate what to expect before i visit a space (e.g. a room in a cellar or the 4000 m2 mega monster space).

[the-metalgamer]

Wouldn't it be better to use an array with object in it, so we could specify the different rooms?

Something like this:

"rooms": { "description": "A list of the rooms in your space", "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string", "description": "The name of the room" }, "description": { "type": "string", "description": "A description of the room" }, "area": { "type": "number", "description": "The size of the room" }, "unit": { "type": "string", "description": "The unit for the area of the room" } } } }

[gidsi]

Wouldn't it be better to use an array with object in it, so we could specify the different rooms?

Something like this:

"rooms": { "description": "A list of the rooms in your space", "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string", "description": "The name of the room" }, "description": { "type": "string", "description": "A description of the room" }, "area": { "type": "number", "description": "The size of the room" }, "unit": { "type": "string", "description": "The unit for the area of the room" } } } }

I was thinking about it, but i think it's a bit toooo detailed. You can't really grasp what the room is for if you're not a member of the space. Like a workshop for instance, is it for metal or wood? Or is it just a cutting board for 3d prints? So this wouldn't help somebody unless we have a defined list. And also i don't think a lot of spaces know how big the rooms/areas are, but i think everybody know how big their whole area is.

Don't get me wrong, i want to know whats possible there too, like is there a social area? Is there desk space? Is there a place for painting or surface finishes? And stuff like this, but i don't think a room list would help me or others as much (areas could be used for more then one thing for example) :)

[the-metalgamer]

I understand what you mean. But I would at least include a unit property, because some cultures can get a better grasp of square feet than square meters. I would also only allow square feet and square meters.

[gidsi]

I understand what you mean. But I would at least include a unit property, because some cultures can get a better grasp of square feet than square meters. I would also only allow square feet and square meters.

I was thinking about that too :)

I didn't add it since it adds more complexity, it's easy to transform sq. ft to m² (roughly divide by 10), its something that could be solved in a frontend and as far as i know it's only the U.S. that really uses sq. ft.

From my perspective we should drop all non-SI units (with temperature an exception since conversion is a pain in the ass and its probably used internally anyways) and let the frontends do the conversion (you have to ask the user which units should be used anyways, and this way you just have to implement conversion in one direction and not implement conversion from everything into everything).

Right now we support a lot of historic temperature scales or e.g. knots in wind speed (elevation for the sensor is just allowed in meters though)

[the-metalgamer]

Depends, maybe some need to do the conversion also in the backend, when they gather sensor data. For this it is of course irrelevant, because the area doesn't change often.

[dbrgn]

Cool! That's a great idea, and I totally agree that it should be added :smiley:

Wouldn't it be better to use an array with object in it, so we could specify the different rooms?

Yes, that would be nice. In our case we have a "makerspace" and a "hackerspace" that are separate rooms, so having a way to distinguish those rooms would be great. If you have a 40m² hackspace and a 100m² storage room in the attic that is not the same thing as a 140m² hackspace.

However, I'd call it "area" instead of "rooms", so that people can enter their total area if they prefer that. It should be up to the space to decide how detailed they want to provide that information.

I was thinking about it, but i think it's a bit toooo detailed. You can't really grasp what the room is for if you're not a member of the space.

Does that matter? If an application wants to show the total area, then it would simply sum up all the rooms and ignore their names :slightly_smiling_face: Also, we can provide free-form description fields, just like with sensor values.

And also i don't think a lot of spaces know how big the rooms/areas are, but i think everybody know how big their whole area is.

I would disagree with that. If people are capable of running a hackerspace they're also capable to measure their space area :slightly_smiling_face: And if not, you can always just add a single entry called "Hackerspace" or "Total area" with the total area (as long as we don't call the key "rooms").

But I would at least include a unit property, because some cultures can get a better grasp of square feet than square meters

No, please, don't! Localizing the unit is the job of the application that displays the information (e.g. a mobile app), not the job of the interchange format. Let's stick to SI units.

My suggestion would be (with size being square meters):

"area": [
  {"name": "Hackerspace", "description": "Our hackerspace area", "size": 100},
  {"name": "Makerspace", "description": "Our workshop", "size": 100},
]

...or if you prefer total area:

"area": [
  {"name": "Total area", "size": 200},
]

For an application, to show total area (pseudocode):

let total_area = space.area.map(k => k.size).sum()

[gidsi]

Wouldn't it be better to use an array with object in it, so we could specify the different rooms?

Yes, that would be nice. In our case we have a "makerspace" and a "hackerspace" that are separate rooms, so having a way to distinguish those rooms would be great. If you have a 40m² hackspace and a 100m² storage room in the attic that is not the same thing as a 140m² hackspace.

That's kinda my point. It's a very good example.

I've talked a lot about the difference between a hackerspace and a makerspace. And in the end it's not that simple and very individual. The definition of a hackerspace and a makerspace are very, very similar (so similar that people are using makerspace instead of hackerspace usually if they want to avoid the negative conotation of the word "hacker"). Basically having a makerspace and a hackerspace would mean that you have two groups (which can be the same in general, but you would need to be able to be part of one and not of the other). So having these listed as seperate rooms doesn't give me any information since its highly depending what your definition of it is and how you separate them (maybe it's even the same area).

I was thinking about it, but i think it's a bit toooo detailed. You can't really grasp what the room is for if you're not a member of the space.

Does that matter? If an application wants to show the total area, then it would simply sum up all the rooms and ignore their names slightly_smiling_face Also, we can provide free-form description fields, just like with sensor values.

But they might not provide all areas. Also it's kinda complicated to distinguish, is a shelf in a workshop part of the storage area or part of the workshop?

And also i don't think a lot of spaces know how big the rooms/areas are, but i think everybody know how big their whole area is.

I would disagree with that. If people are capable of running a hackerspace they're also capable to measure their space area slightly_smiling_face And if not, you can always just add a single entry called "Hackerspace" or "Total area" with the total area (as long as we don't call the key "rooms").

For that you have to measure your whole hackerspace (and people are lazy, which leads to less spaces providing the field, the total size is usually widely known since its on the lease).

I can't do a lot with the information, i don't know what i can do in a 100m2 hackerspace since it depends on whats there. Is there a projector so i can do a presentation? How many people will fit? Is there a desk with an external monitor that i can use? I can't even sum them up if there is a Hackerspace and a Total Area object.

To know whats I can do there i would rather go with another field, listing possibilities, like: deskspace computer workstation large wood builds large metal builds soldering painting etc.

This way i could see what i could do there before actually going (it's not perfect yet, the list could get very long and it's saying nothing about the quality).

With area_size field i want to give people who don't know the space an estimation how big it is (for e.g. taking enough time to see everything).

[dbrgn]

Hm, I don't really know why the definition of a hackerspace and a makerspace matters. In our case, this is our terminology to differentiate what the two areas are for, but of course their use overlaps. The description can help to explain what it means.

If you're saying that specifying "we have 100m² hackcenter, 50m² electroncis lab and 20m² of hanging out area" doesn't help the user because they don't know what to expect, why is "we have 170m² of something" better in any way? The first approach conveys much more information.

My proposal was not to standardize the names. They're free-form names and descriptions that are chosen by the spaces themselves. But if I know that a space has 200m² area, that gives me less information than if I know that the space consists of a 200m² biolab, so I won't expect a sewing area.

I think it would be sufficient to add a note to the spec that people should include their entire space and not just parts of it, and that entries should be non-overlapping (so either "total area" or listing all the rooms). Or, in other words, the "area" key should describe their entire available area.

[gidsi]

Hm, I don't really know why the definition of a hackerspace and a makerspace matters. In our case, this is our terminology to differentiate what the two areas are for, but of course their use overlaps. The description can help to explain what it means.

Yes, exactly. It's the definition of the space. Of the people using it. And they already know how big the areas are. Having to add the description already shows me that it's very complicated to communicate if you separated the different areas.

If you're saying that specifying "we have 100m² hackcenter, 50m² electroncis lab and 20m² of hanging out area" doesn't help the user because they don't know what to expect, why is "we have 170m² of something" better in any way? The first approach conveys much more information.

But not usable information. Hackcenter might be an area with just tables and seats, maybe it's couches and an area to socialize, maybe its soldering and electronics.

What do i do with the information?

My proposal was not to standardize the names. They're free-form names and descriptions that are chosen by the spaces themselves. But if I know that a space has 200m² area, that gives me less information than if I know that the space consists of a 200m² biolab, so I won't expect a sewing area.

Didn't expect that to be a name standardization :) I think that would be a hard edge case. What about places that just list a kitchen and do biolab stuff in there? As i said the area list doesn't give me a lot about what to expect.

Having the total size gives me a rough estimation of how much time i might need to visit. E.g. if its 4000 m2 like Artisan Asylum i would take a day. If its just 20 m2 like the space in Essen 10 years ago i might just plan 1-2 hours and i could squeeze that in somewhere.

Like, i completely underestimated the time i would need to visit i3 (don't remember correctly, but something like 800-1200 m2) but i completely overestimated the time i needed to visit inventeaza (just two small rooms). Which made me rush through i3 and not having time to mingle, and having way to much time in inventeaza and get bored.

I think it would be sufficient to add a note to the spec that people should include their entire space and not just parts of it, and that entries should be non-overlapping (so either "total area" or listing all the rooms). Or, in other words, the "area" key should describe their entire available area.

I would be fine with that if we have very precise guide lines how to do that. I'm afraid that's very hard to do and have a proper outcome that will fit for most spaces and i don't think a lot of spaces would do that when it is complicated to do.

[rnestler]

{"name": "Hackerspace", "description": "Our hackerspace area", "size": 100},

Would you just name it size without any indication of the unit? I'd just name it square_meters. So you end up with:

"areas": [
{"name": "Hackerspace", "description": "Our hackerspace area", "square_meters": 100},
]

Accessing it would be very naturally like: areas[0].square_meters.

[dbrgn]

I'd just name it square_meters.

Hm, yeah, that might be clearer.

But not usable information. Hackcenter might be an area with just tables and seats, maybe it's couches and an area to socialize, maybe its soldering and electronics.

What do i do with the information?

You interpret it :slightly_smiling_face: By that reasoning, a space providing a description of their rooms on their website would be useless because if the space writes "we have an an electronics lab" that could mean anything :wink:

@rnestler @the-metalgamer @s3lph @g5pw any other opinions on this? Current question is whether

"area": [
  {"name": "Hackerspace", "description": "Our hackerspace area (electronics lab, soldering area, 3D printing, desk area, vintage computers, etc)", "square_meters": 100},
  {"name": "Makerspace", "description": "Our workshop (woodworking, power tools, etc)", "square_meters": 100},
],

...or

"area": 200,

...would be better.

[gidsi]

You interpret it slightly_smiling_face By that reasoning, a space providing a description of their rooms on their website would be useless because if the space writes "we have an an electronics lab" that could mean anything wink

Exactly my point, i think having to interpret something is bad, having to display data that need to be interpreted is very hard and is a source of mistakes and misunderstanding :)

A lot of spaces give a detailed explanation of what you can do there, or the equipment that they have if they list their areas. I like that a lot better and i would like to work on that on a different field.

[the-metalgamer]

Well, it's complicated. Specifying areas is difficult, because for example we have multiple areas in a room. So with my example, I would not list every area, but I would list the two rooms we have, because we do not own a whole building but only two rooms. So that's why I went with rooms. So the question is what is defining a room, because I can think that there are spaces who don't have separate rooms, but many areas. So here it makes more sense, to list areas because else they would only have a big room.

So basically the two different options, one listing the rooms and one specifying only the total size, have their advantages, but also their disadvantages.

We could also go with a middle way, by using the total area and adding a areas/rooms key with an array of objects, listing a name, description and url for the room/area, which can be free form. So the spaces have the possibility to list their rooms/areas. The url should point to a a page, where it is explained, what one could do there, in more detail.

[dbrgn]

Replaced by #107.